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The TDRSS Management Story 


by Robert 0. Aller 

Former Associate Administrator, Office of Space Operations 

NASA Headquarters 


NASA initiated the Tracking and Data Relay 
Satellite System (TDRSS) Program in 1973 to 
acquire a new capability for tracking and data 
acquisition from NASA spacecraft in low 
Earth orbit through the use of data relay satel- 
lites in geosynchronous orbit. The data relay 
satellites would relay communications first 
between user spacecraft and an Earth station 
in the continental U.S., then to and from the 
NASA mission control and data processing 
centers. A principal objective was to provide 
the almost continuous coverage of low-orbiting 
spacecraft (including the Space Shuttle and 
Spacelab), which is possible from a geosyn- 
chronous orbit, contrasted with the limited 
visibility of low-orbiting spacecraft provided 
by the network of ground stations then in use. 
Equally important was the need to meet re- 
quirements for the very high data rates (50 to 
250 megabytes per second) which were being 
projected for Spacelab and the free-flyer, 
Earth-observation satellites. 

In the intervening years, the TDRSS program 
evolved to become, from a program manage- 
ment and contract management viewpoint, 
one of the most complex and challenging pro- 
grams in the NASA experience. Problems be- 
gan with the approach taken in initiating and 
implementing the program and with program- 
matic actions stemming from that approach. 
Other problems were caused by delays in 
Shuttle launch availability, especially the ex- 
tensive delay after the Inertial Upper Stage 
(IUS) rocket failure in 1983 and the loss of 
Tracking and Data Relay Satellite-2 (TDRS-2) 
in the 1986 Challenger tragedy. Nonetheless, 
problems were overcome through dedicated ef- 


forts of both the government and industry 
team members, and today, TDRSS stands as a 
success story. The space-based tracking and 
data acquisition network envisioned in the 
early 1970s is now in place and is performing 
well. NASA has received more data through 
the TDRSS than through all ground tracking 
and data systems worldwide since the initi- 
ation of space activities. The support provided 
to date to the Space Shuttle and Spacelab and 
to free-flying spacecraft in Earth orbit has ful- 
ly confirmed the operational concepts which 
led to the initial approval of the program. 

In this article, I will review the management 
history of this program, revisit the contractual 
and management problems encountered, and 
present an assessment of the experiences 
gained, to identify "lessons learned” which 
may be of benefit to NASA in the planning and 
management of programs of this nature in the 
future. 

The Program Start 

As early as the late 1960s, NASA realized that 
the ground network, even on an expanded and 
upgraded basis, could not meet the technologi- 
cal needs of the relatively near future. Data 
rates were increasing beyond the capacity of 
the network equipment and, moreover, the 
necessary geographical dispersion of the sta- 
tions had limited coverage of spacecraft data 
transmissions to about 15 percent of the orbit 
for most low Earth orbital spacecraft. It would 
have been possible to upgrade the ground sta- 
tion equipment to overcome the data rate defi- 
ciency partially, but it would have been very 
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costly to do so, and geographic expansion of 
the system was impracticable if not impossi- 
ble. NASA was already experiencing political 
problems with certain ground stations located 
in foreign countries. Even with augmenta- 
tion, the need for almost continuous coverage 
could not be realized. 

If, on the other hand, NASA could develop a 
tracking and data network system in geosyn- 
chronous orbit, high data rate transmissions 
could be received in real-time and relayed di- 
rectly into a single ground station for about 85 
percent of the time from all low Earth orbiting 
spacecraft, thereby permitting most of the 
ground-based network to be phased down. The 
circumstances themselves led to the only prac- 
ticable decision that NASA could make — an 
in-orbit tracking and data acquisition net- 
work. This approach was supported by a num- 
ber of conceptual design studies, both in-house 
and contracted, to determine the feasibility of 
such a system. By the mid-1970s when it was 
necessary to make the final decision, it was 
felt that the required technology was already 
in hand. 

The NASA budget environment was unusual- 
ly constrained at that time. The costs of devel- 
oping the Shuttle was devouring a major share 
of the budget to the extent that it was difficult 
to maintain a balanced space research and ap- 
plications program. The TDRSS program was 
first proposed to the Administrator as a con- 
ventional NASA-developed and implemented 
system. However, the Administrator was re- 
luctant to commit the up-front funding which 
would have been required for such a program, 
feeling that the constrained NASA budget re- 
sources should instead be reserved for the 
Shuttle development and other space research 
and development programs. TDRSS was view- 
ed more as an operational support system, and 
there were precedents for obtaining such ser- 
vices from the private sector, such as the 
NASA Communications Network (NASCOM) 
for communications support of NASA flight 
missions. 


The Procurement Phase 

In this environment, and after much discus- 
sion within NASA and with Congressional 
committees, the decision was made to acquire 
the TDRSS capability from the private sector 
under a long-term service arrangement rather 
than to pursue a NASA-developed and owned 
system. It was also felt that savings to NASA 
could result if the contractors were permitted 
to propose a shared-service system containing 
separate commercial communications capacity 
along with the required NASA communica- 
tions capabilities. In either scenario, the con- 
tractor was to design, finance, and build the 
system to meet NASA performance specifica- 
tions, and operate the system and provide ser- 
vices to NASA over a 10-year period, with no 
payments to be made to the contractor until 
acceptable services actually began. All this on 
a fixed-price contract basis! Such an arrange- 
ment would allow the project to proceed on a 
timely basis, and NASA could defer inclusion 
of funds in its annual budget until it came 
time to pay for the services, presumably after 
Shuttle development had been completed. 
Special legislation would be required to allow 
NASA to incur a liability in the absence of ap- 
propriated funds and so avoid violation of the 
Anti-deficiency Act. With the concurrence of 
the Congress, NASA planned to enter into this 
off-budget financing arrangement, even 
though it was totally alien to its normal mode 
of doing business. 

As it evolved, however, the prospective con- 
tractors were not able to provide the multi- 
million dollar funding for the project from 
their corporate resources nor to obtain financ- 
ing from the usual financial institutions. (Re- 
member, this was before the days of "junk 
bonds.”) It had been assumed that a 10-year 
NASA contract would be adequate security, 
but the financial institutions would not pro- 
vide loans without a "full faith and credit” 
backing from the U.S. Government. NASA it- 
self did not have authority to enter into such 
an agreement; it would have required a state- 
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ment from the Attorney General’s office. How- 
ever, at that time, an alternate financing ar- 
rangement was suggested to NASA by a repre- 
sentative of the Federal Financing Bank 
(FFB), a component of the U.S. Treasury De- 
partment. Under this arrangement, construc- 
tion loans would be provided directly to the 
contractor by the FFB, with NASA assuming 
the role of guarantor of the loans. This had the 
advantage to NASA of a lower interest rate on 
the loans than would have been obtainable 
through the commercial institutions, even 
with "full faith and credit” backing. 

The Request for Proposal (RFP) entailed the 
development of a service and performance 
specification rather than a design specifica- 
tion. When services are acquired from the pri- 
vate sector, the performance parameters of an 
existing commercial system are already 
known. It then becomes a matter of determin- 
ing if the commercial service will fulfill the 
government requirements. Here, however, it 
was necessary for NASA to specify in advance 
its own requirements as known or projected at 
the time for the planned 10-year service peri- 
od, and really extending for 13 years ahead 
since it was expected that it would take about 
three years to design and build the system. As 
it turned out, some very important perfor- 
mance needs were not fully recognized at the 
time. 

The RFP was issued in February 1975 for a 
two-phase procurement. After final proposals 
from two contractor teams were evaluated, the 
contract was awarded in December 1976 to 
Western Union Space Communications Com- 
pany teamed with TRW and Harris Corpora- 
tion, for development, implementation and op- 
eration of the TDRSS for 10 years of service to 
NASA. In addition, the space segment would 
have systems capabilities for Western Union’s 
commercial satellite communication services, 
thus constituting a shared system in what was 
viewed as a joint venture with industry. 


Problems and Their Solutions 

The first major problems arose shortly after 
the project was under way. Potentially severe 
radio frequency interference, caused by high- 
power radio frequency energy bursts originat- 
ing in eastern Europe, appeared to make full 
operation of the system questionable. The 
problem needed immediate correction. The 
RFP had specified performance criteria but 
had not cited the specifics of the radio frequen- 
cy operating environment; NASA had, at this 
point, approved the contractor’s proposed sys- 
tem design; and, most troublesome of all, it 
was a fixed-price contract. 

Had this been the usual cost-plus-fixed-fee 
contract for a government-owned system, 
NASA would have been able to get involved in 
the immediate system redesign, issue a 
change order, and get the project moving with 
a minimum of loss of time and with some con- 
trol over cost. In this "hands-off,” leased- 
service mode, however, NASA was thrust into 
an engineering situation completely foreign to 
its culture. The project management office 
had been staffed at a minimal level considered 
appropriate for managing the service con- 
tract, but clearly not adequate for the in-depth 
technical design review and control of a con- 
ventional NASA space systems procurement. 
On the other side, Western Union, the prime 
contractor, with its orientation toward com- 
mercial communications services, had but lit- 
tle aerospace systems development experience 
or background; the subcontractor, TRW, had 
this experience and knowledge, but was not 
part of the NASA/contractor interface. Hin- 
dered by limited contractor access and pre- 
cluded by the contract from giving technical 
direction, NASA became burdened with un- 
seemly project delays and added expense. This 
was only the first of many circumstantial 
events that restricted NASA’s ability to exer- 
cise technical management and control of the 
project. 
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Technicians transfer the Tracking and Data Relay 
Satellite and its Inertial Upper Stage, the primary 
cargo for STS -6, into the transport canister. 


Other engineering changes, particularly in 
the ground station, resulted from new or 
changing operational requirements. Some of 
these came from the growing need for more 
stringent communications security provisions 
for the command and control systems. Usual- 
ly, such changes to handle mission-unique re- 
quirements had to be made on the contractor’s 
side of the system interface, a troublesome and 
usually costly process under a fixed-price con- 
tract. 

The original contract contained provisions for 
penalties to the contractor for failure to meet 
specified levels of performance in the system. 
These were intended to promote a systems de- 
sign with sufficient redundancy to assure reli- 
able operations. However, the contract cost 
growth caused by engineering changes and re- 
peated launch delays effectively eroded the 
penalty provisions to the point where the con- 
tractor would find it more cost-effective to 
skimp on redundancy and reliability and in- 
stead accept the risk of penalties for poor per- 
formance. In the ground station in particular, 
the contractor cut back significantly on the 
level of redundancy and even on the level of 
performance from the initial design proposal, 
contending that this system would still meet 
NASA’s service specifications as given in the 
RFP. This type of situation led to many dis- 
agreements between NASA and the contrac- 
tor, some of which had to be resolved by a 
change order and additional costs. 

Since TDRSS was a leased-service type of pro- 
curement, it had not been subjected to the 
same type of end-to-end systems engineering 
analysis that would be normal in development 
of a NASA space mission support system, and 
the service and performance specifications ex- 
pressed in the RFP did not bring forth a sys- 
tem design flexible enough to accommodate 
some of the changes in operational require- 
ments. 
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Another major problem arose from the inter- 
dependency of the TDRSS Project with other 
projects. The original schedule for launching 
the first three TDRS spacecraft was based on 
using the Atlas-Centaur, followed by the Shut- 
tle/Spinning Solid Upper Stage-Atlas (SSUS- 
A) combination. The SSUS-A was never actu- 
ally produced, and instead, the Air Force’s IUS 
was selected for the upper stage launch. How- 
ever, both the Shuttle and the IUS suffered 
numerous delays. During the same period, ad- 
ditional user requirements were placed on the 
TDRS by the Shuttle and other programs that 
necessitated major engineering changes to the 
TDRSS data system. The repeated lengthy de- 
lays inflicted severe damage on the potential 
for commercial service envisioned by Western 
Union, because service date plans for commer- 
cial service could no longer be met. 

At the same time, serious conflicting view- 
points arose between NASA and Western 
Union over many issues associated with the 
shared system: cost allocations, impact of engi- 
neering changes on schedules, priorities of 
NASA requirements versus commercial re- 
quirements, etc. The net result was that West- 
ern Union and NASA reached agreement in 
late 1982 for NASA to acquire rights to the 
complete transponder system, including the 
commercial capacity, bringing the joint ven- 
ture to an end. This agreement also changed 
the fixed-price arrangement of the operations 
phase to a cost-plus-award-fee contract that 
would allow much more flexibility for NASA. 
The development and implementation phase 
remained fixed-price. 

By the time of the first launch in April 1983, 
the project was more than three years behind 
schedule. TDRS-1 was launched on the Shut- 
tle with an IUS developed by the Air Force. 
The IUS rocket motors failed to burn properly, 
however, and injected the TDRS into an ellip- 
tical orbit rather than into the desired geosta- 
tionary orbit. Ironically, the fact that the 


spacecraft had been designed for dual govern- 
ment/commercial service saved the day. Us- 
ing fuel ordinarily reserved for commercial 
purposes, a team of government and contrac- 
tor personnel devised a series of maneuvers ef- 
fected with one-pound thrusters over the next 
several months which placed the spacecraft 
into its proper orbit. By December 31, the 
TDRSS was declared to have begun providing 
services. TDRS-1 has performed well since 
that date, and has been joined in orbit recently 
by two more TDR satellites to establish an 
operational system. 

The 'Lessons Learned’ Workshop 

With the publication of the Reagan Adminis- 
tration Space Policy in 1988, a renewed em- 
phasis was placed on the desire to commercial- 
ize to the greatest extent certain new space 
project undertakings. High-level discussions 
between NASA officials and Administration 
policy-level representatives confirmed the in- 
tent of the Administration to move aggressive- 
ly toward this manner of operation. Internal 
discussions ensued at NASA, and we began a 
serious review of upcoming programs to see 
what might be done to respond to this new ini- 
tiative. 

One aspect of this review focused on the joint 
venture between Western Union and NASA, 
and on the leased-services approach to involve 
the commercial sector in such a joint venture. 
As a result, I felt that it would be useful to re- 
visit the TDRSS experience to see what les- 
sons might be learned that would assist us in 
dealing with the commercialization program. 
To that end, I called together about 30 present 
and former NASA and industry people who 
were closely involved in the development and 
execution of the TDRSS project, to review its 
successes and its problems, and to identify 
"lessons learned.” The major findings of the 
group follow. 
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LESSONS LEARNED 

Shared Service Concept. The concept of 
combining a commercial need with an estab- 
lished NASA need is valid, and may offer sig- 
nificant savings to the government through 
shared costs; however , the rights and oper- 
ational utilization needs, availability, and 
privileges of each party must be clearly estab- 
lished in advance. 

The proportions of cost for the shared TDRSS 
space segment was approximately 20 percent 
for Western Union and 80 percent for NASA. 
Under proper conditions, such an arrange- 
ment could benefit both parties. In this case, 
however, serious conflict of interest problems 
arose over many elements of the program — de- 
sign changes, launch vehicle selections, and 
delays in the launch dates. It was a situation 
where the parties had different motivations: 
NASA was concerned with assuring the most 
effective performance for NASA missions, 
while Western Union was driven by the neces- 
sity to profit from communications services. 
That this set of circumstances eventually led 
to dissolution of the "partnership” does not di- 
minish the possibility of shared service, but 
does focus on the need for totally clear under- 
standing from the beginning. The priority of 
the government’s service requirements must 
be clearly set forth at the outset if that service 
is critical to a government mission operation. 

Leased-Service Concept. A leased-service 
concept should be based on the use of available 
commercial services or existing system technol- 
ogy if service is mission-critical. 

There was much more development required 
for the design and implementation of this pro- 
gram than had been apparent in the beginning 
due, in great measure, to the changes in re- 
quirements after the contract was in place. 
The TDRS services were critical to NASA’s 
mission. With the realization that major 
changes were required, NASA reacted by at- 


tempting to influence the design to ensure via- 
bility of the program purpose. The service- 
level specification, however, did not permit 
NASA to specify a design change; only a 
change in service requirements could be initi- 
ated under the contract. A very serious defi- 
ciency of this arrangement was NASA’s in- 
ability to provide to the contractor specific ex- 
perience in spacecraft and ground systems de- 
sign, experience that could have benefited reli- 
ability and performance issues. 

Interdependency with Government- 
provided Services. The interdependency of 
government-provided services to the establish- 
ment of a shared-lease service should be avoid- 
ed or minimized to avoid government impact to 
the enabling of the leased services. 

The original contract specified that the first 
three TDR satellites would be launched on 
Atlas-Centaurs, which were, of course, fully 
developed operational launch vehicles. The 
next three TDR satellites would go on the 
Shuttle/SSUS-A, later changed to the Shut- 
tle/IUS, all of which were still under develop- 
ment at the time of the contract. 

However, early in the contract, the spacecraft 
design was outgrowing the Atlas-Centaur load 
capability. Spacecraft weight reductions could 
be made only by unacceptable reductions in re- 
dundancy and other reliability provisions, and 
it soon became necessary to shift the first 
three TDR satellites to the Shuttle/IUS. The 
subsequent Shuttle and upper stage vehicle 
development delays made it impossible to 
maintain the program schedule, impacting the 
Western Union commercial communications 
as well as services to NASA. In agreeing to 
provide launch services, NASA had, in effect, 
become a subcontractor to its own prime con- 
tractor for TDRSS services. This complex in- 
terrelationship complicated the lines of re- 
sponsibility, placed NASA directly in line to 
the success of Western Union’s efforts, and led 
to conflicts of interest in questions of launch 
delay, scheduling, etc. 
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Fixed-price Contract for Developmental 

Work. A fixed-price contract is not appropri- 
ate for development of a mission-critical sup- 
port system where significant technology devel- 
opment may be required or where substantial 
changes to requirements may occur. 

The nature of the fixed-price contract made 
close technical direction very difficult. The 
contract specified certain services that were to 
be provided; therefore, NASA could not read- 
ily control the systems design or make 
changes to it. Technical direction, as tradi- 
tionally practiced by NASA, was not possible. 

In addition, the project management structure 
was inappropriate for what became a develop- 
mental program. The prime contractor, West- 
ern Union, had little background in the aero- 
space technology necessary for a successful 
project. Their subcontractors were TRW for 
systems integration and Harris Corporation 
for the ground station; Harris was also sepa- 
rately a subcontractor to TRW to provide the 
spacecraft antennas. The formal NASA- 
contractor interface could not function in the 
normal manner. This eventually led to an in- 
formal interface between NASA engineers and 
those of TRW and Harris, simply in the inter- 
est of keeping the project moving. 

Government Control under Leased Ser- 
vice. Under a leased-service arrangement, 
NASA must accept some loss of control over 
physical assets and accept risks of system out- 
ages or failures. 

Effective control of the TDRSS assets was in 
the hands of Western Union as owner of the 
system. Under such an arrangement, the only 
way that NASA could influence the design of 
the system and, in effect, the quality of ser- 
vices was by specifying service requirements, 
including penalty clauses to the contract for 
failure of the contractor to provide the re- 
quired services. In this particular case, the 
penalty clauses were not fully effective, due to 
inflation and NASA-induced technical 


changes. When the original basis for the pen- 
alty clauses no longer existed, the contractor 
was relatively free to take actions that might 
reduce the level of service without incurring 
undue monetary risk. 

Operational Interface. In a fixed-price envi- 
ronment, establish the government/contractor 
operational interface at a point where changes 
in requirements affect only the government 
side, so far as possible. 

In developing the Request for Proposal for 
TDRSS, the prime effort was to define service 
capabilities that would meet the requirements 
of future NASA missions in low Earth orbit. 
The system was planned to have a broad enve- 
lope of capabilities that would handle the pro- 
jected needs of the users over the 10-year ser- 
vice period without major changes to the sys- 
tem. However, unanticipated changes in re- 
quirements began to emerge soon after the 
contract was in place. Efforts were made to 
confine the impact of such changes to the 
NASA side of the interface, and thereby not 
perturb the fixed-price service contract. How- 
ever, as this was often not practicable, con- 
tract modifications then had to be made, par- 
ticularly in the ground system, which had sig- 
nificant cost as well as schedule impacts. 

End-to-end Engineering and Operations 
Analysis. In a leased-service approach to ob- 
taining a mission support capability , it is just 
as essential initially to establish a comprehen- 
sive end-to-end systems engineering analysis 
and an operations and testing plan as would be 
done in a conventional NASA space system de- 
velopment program. 

Probably because of the view of TDRSS as a 
service procurement, there was not enough at- 
tention given initially to a systems engineer- 
ing approach for the total end-to-end system — 
the Network Control Center, the Project Oper- 
ations Control Centers, etc., as well as the 
TDRSS. Operational concepts that would 
have correlated the designs and the require- 
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ments of all portions of the overall system 
were not developed until late in the game. The 
result was unnecessarily complex interfaces 
among elements of the overall system which 
might have been avoided by utilizing a sys- 
tems engineering approach from the begin- 
ning; in that way, operational concepts would 
have been defined at an early stage. 

Considerations for Prime Contractor. The 
prime contractor must be one who has an exten- 
sive background in the business at hand. 

When the RFP was issued calling for a long- 
term service, there appeared to be a perception 
in the aerospace and communications indus- 
tries that a communications carrier was the 
proper type of company for the effort. The ini- 
tial proposals received by NASA were in that 
structure. It is quite possible that the initial 
demands for capital to finance the project led 
some to believe that only huge communi- 
cations-oriented companies would be able to 
fund such a venture. Regardless of the moti- 
vation, the prime contractor’s limited expo- 
sure to aerospace systems technology was not 
sufficient for sound technical management of 
the contract. NASA is more accustomed to 
dealing with aerospace firms in terms of sys- 
tem and subsystem design. As the technical 
problems in the system grew, NASA often 
tended to bypass the prime contractor and 
work directly with the subs to resolve the tech- 
nical problems. Thus, de facto decisions were 
frequently made that had not flowed through 
the appropriate management channels. 

Conclusion 

The TDRSS leased-service approach was de- 
signed to involve the commercial sector (i.e., a 
contractor) in developing and implementing a 
new mission support capability for NASA. 
This approach used contractor funding, with 
costs to be amortized and reimbursed to the 
contractor over a 10-year operations period. 
Thus, NASA budget requirements for this ca- 


pability would be deferred until the service 
was actually provided. As it turned out, the 
Federal Financing Bank became the source of 
funding, with NASA guaranteeing the repay- 
ment to the Bank. This was to NASA’s advan- 
tage since the loans were obtained at a consid- 
erably lower interest rate than would have 
been otherwise available to the private con- 
tractor. Budget requirements for the system 
were deferred from the start of the contract in 
January 1977 until repayment to the Bank be- 
gan in late 1983. From a management point of 
view, this arrangement was not a problem for 
NASA to administer. 

Unfortunately, this all took place during a pe- 
riod of high inflation and unprecedented rises 
in interest rates — from 7.5% planned to a peak 
of nearly 16%. These effects, coupled with the 
repeated delays in Shuttle and IUS availabil- 
ity, caused serious cost growth; almost half of 
the present total systems cost is in interest 
charges. However, the cost of these interest 
charges now appearing as NASA direct costs 
would not have appeared in the NASA budget 
had the project been funded in the convention- 
al manner. Instead, the interest costs would 
have been included in the Treasury budget as 
part of the cost of financing government bor- 
rowing. 

The TDRSS will end its sixth year of service on 
December 31, 1989. Even with only one satel- 
lite in operation from December 1983 until 
late 1988, the service provided was far superi- 
or to that provided by the network of ground 
stations. With the launch of the third satellite 
in March 1989, the system is now considered 
operational, and will service NASA’s data ac- 
quisition requirements into the early phase of 
Space Station Freedom. In 1991, a replace- 
ment satellite will be launched to replace the 
first satellite in the system. At this point, 
NASA has achieved what it set out to do — in- 
stall an in-orbit tracking data acquisition sys- 
tem providing 85 percent coverage for all low 
Earth-orbiting spacecraft, leading to the clos- 
ing of all but a few ground stations. 
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We are now approaching the next generation 
of TDRSS operations — an advanced TDRSS 
that will meet the requirements of future mis- 
sions in the late 1990s and on into the next 
century. This undertaking attests to the va- 
lidity of the operational concepts that began 
nearly 20 years ago. It has been a challenge to 
reach this point, and we must now use some of 
the "lessons learned” through this experience 
to help us cope with the problems that we are 
sure to face in the development of this next 
generation of space network systems, as well 
as other government procurements. 


This double exposure by photographer Klaus Wilkins 
uses trick photography to cause the TRW Tracking Data 
and Relay System Satellite to appear to be inside the 
cargo bay of the orbiter Challenger at the Complex 39A 
launch site. 


ORIGINAL PAGE* 

BLACK AND WHITE PHOTOGRAPH 


9 


Project Management and People 


by William R. Marshall 
Retired Manager, Shuttle Projects Office 
Marshall Space Flight Center 


These days a project manager can easily be- 
come so bogged down in the details and inter- 
ruptions of scheduling, costs, and resolution of 
technical problems that it is easy to forget that 
people are an integral part of the total equa- 
tion. One of the manager's primary responsi- 
bilities to employees is to motivate them. 

Motivation is no easy task. A motivated em- 
ployee works to get the job done; not just to 
earn a paycheck. The manager's responsibil- 
ity is to create the conditions that will lead the 
employees to want to do their jobs. 

A motivated employee, by definition, has a 
sense of pride and self-worth. The manager 
can help to instill these qualities in three basic 
ways: by setting an example, by demonstrat- 
ing understanding, and by recognizing the em- 
ployee's accomplishments. 

Setting an Example 

An effective manager leads by example. En- 
thusiasm about the projects undertaken, 
steady and effective work habits, and support 
of the employees in their efforts to support the 
project, lead to effective work. 

A corollary of leading by example is informal 
communication. The manager must keep in 
touch with the employees. The manager 
should practice MBWA: Management By 

Wandering About. By spending time with the 
employees, informally, the manager will be 
aware of what they are doing and what their 


problems are before the problems become big. 
The manager will be available to them when 
they have ideas and new solutions to problems 
that arise, and will be more receptive to their 
input into the projects they are all working on 
together. This informal give and take gives 
the employees a sense of teamwork, of owner- 
ship of the projects, and reinforces their sense 
of pride and self-worth, or motivation. 

The wandering about technique was applied 
by J.R. Thompson when he assumed the Cen- 
ter Director position at Marshall Space Flight 
Center. Immediately, employees began to re- 
spond throughout the Center organization 
with more informal communications which 
multiplied the data exchange between ele- 
ments by an order of magnitude — or more. 
This approach did not change the need for for- 
mal communication, but multiplied the total 
exchange of information and improved effi- 
ciency. 

The manager must be careful, however, to 
maintain a balance in this system of informal 
communication. Management must continue 
to set an example and to exercise leadership, 
and to walk the fine line between informality 
and comradeship on one hand and formality 
and team effectiveness on the other. Should 
the manager make a mistake, the manager 
will be able to recognize it, admit it to the 
team, take full responsibility for it, and correct 
it. Should one of the team members make a 
mistake, it will be caught and rectified before 
it causes a disproportional problem. 
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Demonstrating Understanding 


Thirty years ago, Douglas McGregor put for- 
ward two opposing theories of management, 
called Theory X and Theory Y. Theory X de- 
scribes people as lazy and irresponsible, and 
professes that they need to be manipulated, 
controlled, and threatened in order for them to 
accomplish anything. They need a sense of or- 
der, control (from above), and security. Theory 
Y says that people have an innate sense of re- 
sponsibility, that they naturally want to work 
and to work well, and that they do best when 
given challenges to their ingenuity and cre- 
ativity. Actually, people tend to respond to the 
way they are treated. If their management ex- 
pects them to be unmotivated and lazy and im- 
poses restrictions to their freedom, then the 
employees are likely to become unmotivated 
and lazy. If, on the other hand, the manager 
demonstrates the expectation that the employ- 
ees will be as dedicated and as motivated as 
management, they will be enthusiastic and 
proud to be working on the team. 

Part of demonstrating understanding of em- 
ployees is knowing their individual strengths 
and weaknesses, and knowing how to take ad- 
vantage of the strengths. Ideally, the man- 
ager will be able to match each employee ex- 
actly to a specific job; if that is not possible, 
perhaps the job can be altered to fit the indi- 
vidual strengths and skills of the employee. 
The results of this understanding are more 
feeling of accomplishment on the part of the 
employee and smoother, more effective func- 
tioning of the team as a whole. 

When new employees are hired, it is not al- 
ways immediately apparent from their work 
history what their special skills are. The ideal 
solution to the problem of where to place them 
on the team is to offer a rotating series of as- 
signments at first, with immediate assessment 
of performance in each. After that, the new 
hire can be placed in the most challenging and 
most effective slot. 


All new employees at Marshall Space Flight 
Center are on a rotational assignment for one 
year. They are placed in three or more organi- 
zations during this time, and both manage- 
ment and they select a "best fit” at the end of 
this assignment. Many new hires do not re- 
turn to the organization that interviewed and 
hired them, a sure indication that rotation 
throughout the organization may provide a 
better fit for employees and the organization. 

To ensure that employees are successful con- 
tributors to the project, the program, and the 
organization, the manager is responsible for 
good, clear communication. The manager 
must make individual work assignments 
clear, show the employees how their activities 
contribute to the organization’s goals, direct 
their activities insofar as necessary, and pro- 
vide them with adequate tools and the proper 
environment for their jobs. 

A good manager will take the risk of reposi- 
tioning current employees to build the future 
of both the employees and the organization. 
The manager is responsible for the employees’ 
success. Perpetuating the status quo of the or- 
ganization, while it is comfortable, can lead to 
stagnation of both employees and organiza- 
tion. Taking the risk of moving people around 
is a sign of an innovative and progressive 
manager, and, done intelligently, results in in- 
creased productivity for the organization and 
greater job satisfaction for the employee. The 
manager who knows the employees and their 
individual capabilities will be able to do this 
intelligently and successfully. Often the man- 
ager can recognize employees’ strengths and 
potential better than the employees do them- 
selves. 

After the Challenger accident, the manager of 
the Space Shuttle Main Engine research and 
development efforts was requested to assume 
responsibility for the Flight Engine operation. 
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This did not fit the manager’s development 
background and was accepted only after con- 
siderable persuasion. Within 18 months, the 
manager had praise for his supervisor’s judg- 
ment of his capabilities and appreciated the 
new assignment. 

Recognizing Accomplishments 

The usual way to recognize outstanding per- 
formance in the workplace is by promotion and 
increase in salary. In some instances, particu- 
larly at NASA, such rewards are not an op- 
tion, because the employee has "topped out,” 
or there is simply no slot available to advance 
into. In those cases, it becomes necessary to 
discover other ways to recognize an employee's 
accomplishments and provide the feeling of 
upward movement. NASA frequently does 
this with awards and special recognition. A 
manager can supplement this with additional, 


interesting assignments, or with organization- 
al "perks.” 

Effective recognition is also personal. The 
day-to-day smile, pat on the back, encouraging 
word, or phone call to express appreciation for 
a job well done works wonders for an employ- 
ee's morale. Say thank you. Of course, the 
employee is just doing the job, but the personal 
additional recognition aids in fueling ongoing 
motivation. 

Recognition consists of both example and un- 
derstanding, and is thus arguably the most 
important of the triad. Recognition is the 
manager's most powerful motivational tool. 
Management is ultimately responsible for the 
success of the project, the program, and the or- 
ganization. Effective managers are effective 
leaders. Good managers grow through exper- 
ience, education, and common sense. 


NEWMAN'S LAWS 

• The length of the justification varies inversely to the dollars involved. 
Corollary: The significance of an item is inversely proportional to the number 
of words it takes to describe it. 

• The more elaborate the cover the less accurate the contents. 

• The probability of creative innovation varies inversely with the 
refinement of the procedures. 

• You can’t hold a staff meeting without a staff. 

Corollary: You can’t supervise them if you can’t find them. 

• Newman’s law of celestial mechanics: The last acceptable launch 
window for any given planetary mission is the one we are trying to get 
in the budget. 

- E. Thomas Newman 
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Managing Projects -- An Industry View 


by S.Z. Rubenstein 

President, Advanced Systems Strategic Defense Center 
Rockwell International 


The project manager is the leader of a team of 
people charged with converting a broad set of 
mission objectives into an operating system. 
Project management is the set of principles 
and processes used by a team to manage a pro- 
ject from its birth to the end of its life cycle. 
These principles and processes encompass all 
the skills needed to plan, organize, direct, 
staff, and control the project. My comments in 
this article are based on nearly 30 years of ex- 
perience in industry serving a variety of cus- 
tomers, including NASA, DoD, other govern- 
ment agencies, and industrial and commercial 
end users. My examples are drawn from the 
Space Shuttle project. 

Essential Concepts: 

Dynamic Process. Committed People, 
Communications 

Today's manager must thoroughly grasp these 
three concepts - have a working knowledge of 
them - in order to successfully run a major 
project. 

First, project management is a dynamic 
process. Managers operate in an environ- 
ment where priorities shift and decision crite- 
ria change as a project progresses. Technology 
progress usually occurs differently than 
planned: funds are being expended, new peo- 
ple are coming aboard, and schedule commit- 
ment dates are coming closer. As a project 
gains momentum, it becomes harder and hard- 
er to shift direction and increasingly more im- 
portant to make timely decisions. 


Second, project success is achieved 
through the hard work of committed peo- 
ple. They are willing to overcome the hurdles, 
surprises, changes, problems, and heartbreaks 
that occur during project life. These people 
can be found at every level: on the factory 
floor, at the engineering workstation, in the 
schedule control office, at the shipping desk, in 
the launch Center, at mission control, in the 
controller's office, in the program office, with- 
in the congressional staff, and also within the 
executive offices. It takes committed people 
from all functions within all involved organi- 
zations to ensure that a project stays within 
performance, cost, and schedule commitments. 

Third, communicating relevant informa- 
tion about the project -- upwards, side- 
ways, and downwards -- is the cohesion 
that keeps the total team in a consistent di- 
rection. Information needs are different at 
each level of the project organization. Infor- 
mation needs at Headquarters to support a de- 
cision made by Congress on future funding are 
different than those of a Center project man- 
ager to support a decision on the allocation of 
resources among project elements. Still differ- 
ent are the needs of an industry line manager 
to support a decision on staffing for a six- 
month period, or a subcontract manager to al- 
locate resources among companies. We often 
make the faulty assumption that all those in- 
volved in the project know what is going on. 
Communicating relevant information, either 
on project status or sharing a problem, is a 
principal mechanism for ensuring that the 
project will be successful. 
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However, before discussion of dynamic pro- 
cess, committed people, and communicating 
relevant information it is further necessary to 
understand two related subjects: quality and 
requirements. 

Understanding Quality: An Attitude 

Quality as a concept is often misunderstood. 
The contemporary definition is "meeting the 
requirements established for the system.” For 
example, the functional requirements at the 
system level, specifications at the end-item 
level, the inspection process at the manufac- 
turing level, and documentation at the test 
level are all requirements to be met. 

Confusion often arises among the concepts of 
quality, safety and reliability, and product as- 
surance. In both manned and unmanned 
space systems, stringent requirements are es- 
tablished for safety and reliability on the basis 
of the consequences of losing the payload or 
the launch vehicle. However, safety and reli- 
ability are similar to other performance re- 
quirements, although their priority in the re- 
quirements tree might be quite high. Similar- 
ly, a set of requirements is established for the 
processes needed to implement product assur- 
ance. Quality, in my view, is an attitude of 
commitment to perform to those requirements. 

In systems design, development, and oper- 
ations, requirements are established to ensure 
a system will do its intended job. Therefore, no 
compromise is made with respect to quality. If 
the system does not meet its requirements, 
then either it must be fixed or the requirement 
re-examined and changed to fit the behavior of 
the built system, if its intended job can still be 
performed. Although this might seem to be an 
extremely expensive way to operate, it is my 
experience that meeting the requirements or 
equivalently building a quality system is most 
cost-effective. The issue is making sure the re- 
quirements are correct; there are no options on 
quality. There is no substitute for producing a 
system that will do the intended job. 


Understanding Requirements: 

The Foundation 

When a project is initiated, the manager has 
three available resources: the mission objec- 
tives; the current state of the art technology 
(in its broadest sense — tools, devices, standard 
specifications, and processes); and collective 
past experience. Very often, the mission ob- 
jectives are a mixture of requirements and de- 
sign. The state of the art of technology weaves 
its way into the requirements by the fact that 
many requirements are, in reality, point solu- 
tions rather than statements of the problem. 
Past experience is very valuable when proper- 
ly used, but all too often we embed require- 
ments that solve a problem no longer relevant 
to the one at hand. These distortions of true 
requirements can limit our ability to use tech- 
nology advances creatively. 

An essential task for the project management 
team is to ensure that requirements are pre- 
cise and operationally valid and that sufficient 
time is allowed to iterate them in order to as- 
sure the simplest implementation. Require- 
ments imposing unneeded constraints and un- 
necessary complication must be changed. In 
the ideal world, the "systems engineering pro- 
cess” should ensure that this task is completed 
before full-scale development begins. Since 
this does not always happen, it pays to scrub 
the requirements hard at the beginning, be- 
fore trouble occurs, rather than wait for a cri- 
sis. I can guarantee that there will be many 
occasions to review the requirements during 
the life of the project. 


LESSONS LEARNED FROM 
THE SHUTTLE PROGRAM 

The Space Shuttle program was unique in that 
only a very few key personnel changes oc- 
curred from the start of development in 1972 
until first flight in 1981. This was true for 
NASA, at Headquarters and the Centers, and 
for the prime contractors. Most projects, how- 
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ever, see a greater turnover during a develop- 
ment period as long as this. This particular 
group of people also had some unique shared 
experiences, having come through the Moon 
landing program and the Skylab program to- 
gether. Many of the people were also involved 
in the earlier Phases A and B (conceptual and 
design) studies and had participated in a very 
large number of trade studies, from configura- 
tion to technology to ground support concepts. 

My experience did not include the early pro- 
grams or trades; and as I started on the Shut- 
tle, I felt as if I were jumping aboard a racing 
train. As soon as I became involved in the 
decision-making process, it became apparent 
that external ground rules and constraints 
were changing, that resources needed to be 
shifted, and that many of the technology 
choices would have to be re-examined. The 
project stayed at this pace throughout the de- 
velopment cycle. Further, it was a resource- 
constrained program, constantly trading 
schedule for current dollars — similar to many 
of today's programs. I will review some of the 
situations that occurred during the Shuttle de- 
velopment and extract some beneficial lessons. 

Requirements and Early Design. During 
the early design phase, there is constant 
pressure to meet drawing release schedules; 
often mistakes can be made by releasing 
drawings before an adequate number of design 
iterations occurs. On the Shuttle project, 
experienced designers often withstood these 
pressures and ensured that their designs 
would meet performance requirements while 
staying within cost and schedule constraints. 
Sometimes — due to pressure or inexperience - 
they did not achieve this balance, for there is a 
fine line between being ready to release and 
embellishing the design. 

The biggest payoff for reducing cost and 
improving operating characteristics occurs in 
the early design cycle. Current concepts, such 
as "Simultaneous Engineering” and "Total 
Quality Management,” involve the total team 


(engineering, manufacturing, test, logistics, 
etc.) early in the design cycle. The objective of 
these concepts is to simplify the total 
production process, recognizing the value of 
design iterations. 



The Space Shuttle Discovery final assembly and 
installation operations took place at Palmdale t CA. 


The system implementation is reflected in a 
series of plans, i.e., engineering, software, pro- 
curement, quality assurance, manufacturing, 
etc. As iterations are made to improve perfor- 
mance, cost, and/or schedule, these plans must 
be kept in step. Early attention to long-lead 
items, critical processes, facilities tooling, and 
test needs will prevent future problems. These 
plans, when properly formulated, are the 
means to communicate direction to the project 
team and measure project progress. As a proj- 
ect manager, one must keep the pace moving 
quickly. One must always balance schedule 
pressure, the quality of the technical output, 
the implementation risk, and cost. 

Mid -course Correction. The time span from 
preliminary design review (PDR) to critical 
design review (CDR) varies from project to 
project. It is a period of significant change: ex- 
penditures are increasing as prototypes and 
breadboards point to the need for technical 
changes. Often annual funding limits and oth- 
er external events result in considerable 
schedule pressure, causing severe competition 
for funds among project elements. As project 
manager, one almost has to anticipate where 
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the problems will arise and be prepared to 
make adjustments. Problems can take the 
form of schedule, dollar, design, or require- 
ments changes. 

During this period, there is time to change the 
implementation characteristics of the system. 
However, project managers should ensure that 
the data they are receiving are real (i.e., they 
must spend time visiting the development con- 
tractors — within the company and at subcon- 
tractor and associate contractor sites). When 
these implementing organizations understand 
the need, the project manager will find that 
their ability to react to change is far better 
than either might think. Not making a deci- 
sion to adjust can be far worse than a non- 
optimal decision. Conversely, constant 
changes can result in chaos. It takes a sea- 
soned team to make the right decisions and 
maintain configuration control. 

The Build Cycle. In the ideal world, produc- 
tion fabrication occurs only after the design is 
thoroughly reviewed, all parts function as 
specified and are received on time, all software 
is received on time and perfectly matches the 
hardware, all subassembly qualifications are 
complete, all assembly and installation pro- 
cesses are perfect, and the expenditures of 
those functions that have finished their work 
are rapidly decreasing. In the real world, this 
rarely occurs. 

Hopefully, the requirements cycle has pro- 
duced good paper specifications and processes, 
and the quality attitude of meeting require- 
ments is well established. If not, the project 
manager is operating on quicksand - this is 
not the time to find out one has missed some 
critical mission objective. The responsiveness 
of the project management team is critical 
during this period. Resources almost always 
need balancing to meet the real rate of 
progress. The project rarely has adequate fi- 
nancial reserves to cover every problem, and 
manpower reserves to meet every contingency. 
However, at this time, the manager will also 
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find that all the scheduled tasks do not have to 
be completed in exactly the sequence specified. 
There is considerable independent parallel ac- 
tivity off the critical path. With proper contin- 
gency planning, a responsive organization, 
and timely decision-making, performance re- 
quirements can still be met within cost and 
schedule commitments. 



Performance of the Space Shuttle’s thermal protection 
system has exceeded expectations. 


I well remember deciding to scrap a marginal 
lot of strain isolation pads (SIPs) used in bond- 
ing the thermal protective tiles to the Shuttle 
vehicle. During screening tests, it appeared 
that 1 to 3 percent of this lot was bad. There 
was enough SIP material to install at least 
1,000 tiles, and this obviously would mean 
that 10 to 30 tiles might not have the proper 
strength. The post-installation tile acceptance 
tests would probably catch the bulk of the 
problem. However, manufacturing and mate- 
rial people developed a workaround plan that 
allowed us to wait for a new lot with minimal 
schedule impact to the total vehicle flow. We 
chose to wait. We updated our process specifi- 
cations at the supplier and at our factory to 
eliminate the possibility of problem reoccur- 
rence. We set the example to our floor person- 
nel that we would accept no less than a quality 
product. And as a result, the thermal protec- 
tion system on the orbiter has performed well, 
even better than expected. 
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Qualification and Preparing for Flight. 
One of the least understood risks in project 
management is caused by lack of attention to 
the acceptance and qualification testing re- 
quired to prepare for both flight testing and 
operations. Too often, proper resource alloca- 
tion in this phase is neglected. (This means 
too little as well as too much.) Each of the 
technical disciplines seems to have its own cri- 
teria as to what needs to be proved by test ver- 
sus how much can be proved by analysis. 
Cryogenic and hypergolic devices always seem 
to provide test surprises. For the Shuttle pro- 
gram, simulation of complete structural loads 
(including the thermal, vibroacoustic, and me- 
chanical acceleration loads) was very difficult. 
Software and avionics integrated testing is al- 
ways questioned relative to its completeness. 
(Are all the possible cases covered, including 
the fault conditions?) Testing to prove life lim- 
its can become very expensive, if not impracti- 
cal. (Consider proving 10- or 30-year life with 
adequate margins.) The physical size of an 
end item and its operational modes (i.e., is it 
reusable, does it have asymmetrical orienta- 
tions?) will determine whether environment 
test chambers can be used. 

Six major steps a project leader can take to 
minimize such risks are: (1) include seasoned 
test personnel on the project team; (2) consider 
the test requirements early in the project life; 
(3) review the test requirements before testing 
begins (e.g., testing gaseous oxygen flow con- 
trol valves, tile test panels, and structural and 
mechanical devices where the culprit was the 
test requirement, test fixture, or procedure 
rather than the device under test); (4) pay at- 
tention to ground and flight test results — es- 
pecially where actual performance diverges 
from predicted performance — since these are 
potential trouble spots; (5) be prepared to 
make some tough decisions on the acceptabil- 
ity of test results versus redesign and retrofit 
versus limited life designation; and (6) not fly- 
ing until problems that affect mission success 
have been resolved. 



Shuttle ground vibration test operations took place at the 
Marshall Space Flight Center. 


Operations. No matter how well one comes 
through the previous phases, the operational 
period will present some unique challenges. 
Flight results, technology evolution, 
turnaround improvements (if reusable), repair 
and wearout, new missions, the desire for 
increased performance, and the next version of 
the system will demand additional effort. 

Frequently, those who authorize additional 
funds, be they Congress or Headquarters pro- 
gram personnel, are not prepared to continue 
investing during the program life. By this 
point, the project team should have some prov- 
en measures to judge the value of any change 
to the system. Too often changes are made 
without an operational set of priorities and the 
result is that systems degrade in performance 
rather than improve. The need for adequate 
technical development, maintenance of con- 
figuration data, and properly planned change 
points is as great now as at any other time. 
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Any change will impact the full range of oper- 
ational tasks, from test and checkout proce- 
dures to training. Careful screening of 
changes and implementation planning will 
keep the system operating successfully for 
many years. Interaction with the ground and 
flight teams will assure that valuable past les- 
sons are not lost and that implementation pro- 
ceeds smoothly. Not responding to valid needs 
for evolutionary change will shorten useful 
life and increase operating costs. 

People: Building Commitment 
and Attitudes 

Project success will depend on the commit- 
ment and attitudes of the people involved in 
the project. The leadership of the project man- 
ager and team is a dominant factor in estab- 
lishing a motivational environment. Too often 
we focus on organizational structure rather 
than behavior. The organizational structure 
of a project can vary from a direct-line project 
team (everyone working for the project man- 
ager) to a highly matrixed organization. 
Which one is the best depends on many fac- 
tors, such as the length of the project, the size, 
the skill mix, and the history of the parent or- 
ganization. All need to be considered, while 
care is taken to balance project responsiveness 
and organizational needs. 

When we had to replace a multiplexer on the 
Shuttle Columbia on the pad at KSC during 
countdown, the only available spare was in 
Palmdale, 3,000 miles away. Within 24 hours 
the spare was delivered, installed, and 
checked out in Columbia; the faulty unit was 
returned to the manufacturer; and the fault 
isolated to ensure we did not have a generic 
problem. Without the commitment of every 
person involved - managers, technicians, lo- 
gisticians, engineers, and pilots (at NASA, 
Rockwell, and the subcontractor) — two or 
more days would have been lost, resulting in 
increased costs as well as some very unfavor- 
able criticism. 



Crew technicians complete a timely repair of STS -2. 


Similar events happen every day in the life of 
a project. The approach the project manager 
and the team take has a great deal to do with 
instilling the commitment and attitudes nec- 
essary for success. The following are tech- 
niques I have seen others use and have used 
myself. 

Building Teamwork. It is important to treat 
all people and organizational elements fairly. 
There is no substitute for ethical behavior and 
technical integrity. Open and honest commu- 
nication among all team members is essential. 
Praise goes much further than blame; and 
criticism should be constructive, especially in 
large meetings. The manager and the rest of 
the team must work hard to establish a project 
outlook, a customer outlook, an end-user out- 
look, and a "can do” attitude. Getting these 
views accepted will obviate many organiza- 
tional squabbles. It is extremely important 
also to build trust and teamwork among orga- 
nizational entities: government, prime con- 
tractor, subcontractors, suppliers, Headquar- 
ters, and Centers. 

Building Consensus. Since decisions are re- 
quired at every level, effective interchange 
must take place with all involved parties. The 
manager listens carefully during the discus- 
sions and then works hard to get everyone to 
accept the decision as the agreed-upon course 
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of action. Rarely are every person's desires 
met. While differences of opinion are accept- 
able, dissension is not. Furthermore, if new 
information becomes available, the issue must 
be revisited. 

Quality is Mandatory. Since a quality prod- 
uct is the project’s objective and requirements 
drive the entire system, all those involved 
know that their commitment to meet require- 
ments will foster product excellence. Estab- 
lishing the means to re-examine require- 
ments, processes, and procedures will also fos- 
ter product excellence. This applies to every 
aspect of the job: to letters and reports, as well 
as the hardware products. Everyone must un- 
derstand the job to be done. In working to 
clean up processes and procedures, the project 
manager will do well to involve the doers as 
well as the writers. This will maintain an atti- 
tude of excellence and result in a quality prod- 
uct. 

Time is of the Essence. Creating a sense of 
urgency is essential for project success. Sched- 
ules are established to ensure that all project 
tasks are synchronized and resources are prop- 
erly applied. Since the manager’s actions and 
team decisions are examples for everyone, 
they should be timely. Adequate time must be 
allocated and the schedule adhered to. The 
project manager must clearly expect schedules 
to be met or beaten and must follow up to 
make sure the proper resources are being ap- 
plied. If difficulties arise, then searching for a 
workaround and eliminating the root cause is 
much more productive than looking for some- 
one to blame. 

Cost is a Driver. Cost is an essential element 
of the contract, and cost-effective performance 
is everybody’s job. All organizational ele- 
ments need to recognize and commit to the cost 
objectives. Getting quality and schedule per- 
formance are major factors in cost perfor- 
mance, and driving for simpler implementa- 
tion improves both. The project manager has 
to ensure that enough time is allowed to get 


the simplifications at the design level and the 
participation of needed disciplines. Life costs 
must be a visible part of the decision-making 
process. 

Keeping in Touch. Too often the project 
manager and team are consumed by meet- 
ings, requests for status, and myriad other du- 
ties which keep them in their own offices. This 
is an easy trap to fall into. But the project 
manager’s presence is needed out on the floor, 
within the organization, at peer organizations, 
and at the contractors’ sites. This presence 
will motivate the workforce, demonstrate con- 
cern, improve the information flow, and in- 
crease team responsiveness. 

Selecting the Right Team. Since there is no 
substitute for talent, the project manager 
must select people who are technically strong 
(i.e., in engineering, manufacturing, schedul- 
ing, contracts, etc.) and who display the com- 
mitment expected. Often, rotation of the peo- 
ple into different assignments will help keep 
the talented people involved and committed to 
the project. Those who do not fit should be en- 
couraged to find other tasks better suited to 
their talents. A strong team will create the 
peer pressure so vital to ensuring an effective 
attitude. 

Reward and Recognition. There are many 
opportunities to reward performance. All too 
often in relations between the government, 
contractors, and subcontractors, profit is used 
as a negative incentive. If contractors meet 
their commitments, they have earned profit. 
If they have stayed responsive to overall proj- 
ect needs, they have earned a good share of the 
profit. If possible, unawarded period profits 
can be effectively rolled forward to provide ad- 
ditional incentives. Similarly, budget under- 
runs can be used to initiate needed work earli- 
er if project resources allow. Incentive and 
fixed-price contracts often allow sharing of 
cost savings that result in additional profits 
for the contractor while saving significant dol- 
lars for the government. Gainsharing 
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is becoming a popular way of passing perfor- 
mance incentives to the individuals. 

There are many ways to provide non-monetary 
incentives to a project team. Commendation 
letters, formal awards, public acknowledg- 
ment, and a simple, spoken "well done” will go 
a long way to building the commitment and at- 
titude needed for project success. 

Communicating Relevant Information 

Some people believe that the answer to all our 
information needs is an infinitely large, auto- 
mated data base with embedded expert sys- 
tems to help us extract the information we 
need to make decisions. Others believe that 
all the key data can be put on three-by-five 
cards and carried by the project team through 
the life of the program. I would like to share a 
situation to help explain my view of what con- 
stitutes relevant information. 

During the approach and landing test on the 
Shuttle program, the Rockwell team had re- 
sponsibility for the vehicle prior to rollout 
from the hangar. We completed the pre- 
rollout tests, moved the vehicle out, and 
passed control to mission control at JSC. On 
one particular flight, we were having some dif- 
ficulties with the inertial measurement unit’s 
alignment. A decision had to be made as to 
whether the observed drift rates would be ac- 
ceptable for flight. Although they were within 
specification and met all the criteria, there 
was obviously something going on that was 
different from our expectations. We had only a 
few minutes to decide whether we were "go” or 
"no-go” for that day. I met with the two re- 
sponsible engineering managers and their rec- 
ommendation was "go.” The information that 
I needed was their technical rationale and how 
they conveyed the data. It was more than the 
numbers: it was also their confidence. Infor- 
mation needs are dependent on the problem at 
hand and the people involved. Information 
consists of more than computer-storable or 
written data. 
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Recognize Differing Needs. Each level in 
the customer, contractor, subcontractor, and 
user organization has different needs for infor- 
mation. Giving everybody everything is al- 
most as bad as giving them nothing. Commu- 
nications must, therefore, be planned in light 
of established performance milestones that 
measure progress meaningful to the level it is 
reported to, in a form useful to the receiver, 
and of value to those who provide it. Status 
data can be verified by frequent site visits. 



In general, the two areas that are served the 
worst are the top of the program, where infor- 
mation is needed to plan future resource allo- 
cations, and the detail working level (includ- 
ing subcontractors), where daily work sched- 
ules are made. The top area needs to under- 
stand the future consequences of any major 
event, and the detail level needs to understand 
current detail status and decisions made that 
affect in-process work. Some effective commu- 
nication techniques are discussed in the next 
sections. 

Use Electronic Information. Modern 
computer-based systems offer tremendous ca- 
pability to provide detailed information to a 
very large number of people. They can be used 
for detailed technical data (drawings, parts 
list, algorithms, system and software require- 
ments, user notes, procedures, etc.). They can 
be used also for scheduling and control infor- 
mation (engineering orders, parts ordering, 
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billing, inventory, configuration data, multi- 
level schedules, etc.) and coordinating infor- 
mation (electronic mail for bulletins, meet- 
ings, decision status, etc.). 

During Shuttle development, it \yould have 
been impossible to complete the program with- 
out computer-based information systems. 
However, difficulty occurred with multi- 
discipline information and multi-level (differ- 
ent user level) data. The fundamental prob- 
lem is that data were not structured into logi- 
cally consistent databases. Inordinate effort 
was required to translate, manipulate, and re- 
format information. Therefore, care should be 
taken on future projects to provide logical 
structures, standards, and user-friendly inter- 
faces to ensure that electronic techniques are 
effectively used. (The NASA TMIS, Air Force 
UNIS, and many corporate information sys- 
tems are working on this issue.) 

Use Meetings to Communicate. During the 
Shuttle development program, many reviews, 
panels, and boards were scheduled on a regu- 
lar basis. Used properly, these were effective 
means for communicating information, as well 
as for making decisions. Daily morning meet- 
ings between project functions at the contrac- 
tor, between organizations at the launch site, 
and between subsystem project managers at 
the lead Center were used to measure the cur- 
rent pulse of the project and resolve issues that 
could impede work. Weekly meetings — such 
as the avionics review board (ARB), technical 
status review (TSR), software control board 
(SCB), change control board (CCB), program 
review boards (PRBs), and vehicle status re- 
views — were ways to facilitate decisions that 
had longer-term impact and to communicate 
results to affected parties rapidly. Monthly or- 
biter management reviews were an excellent 
means for synchronizing all the functions, as 
well as measuring cost and schedule perfor- 
mance. 

The problem, of course, becomes one of how to 
do the work with all those meetings going on. 


With proper attention to meeting duration, 
participation, and completed staff work, these 
meetings are very effective. Letting the per- 
son who is closest to the issue present the in- 
formation and the lowest-level person make 
the decision will speed up the process and 
spread the work. Written minutes, rapidly 
prepared, distributed, and posted for all to see 
will get the information to the "floor” where it 
is often needed the most. 

Consider Contract Data as Important. Too 
often, the contract and its associated state- 
ment of work and schedule of deliverables are 
known only to a limited number of people in 
the project chain - at the customer and at the 
contractor. Yet, the contract is the document 
that communicates the official requirements 
of the work to be done and the schedule for 
when it is to be done. Since government agen- 
cies rarely use the contract as a mechanism 
within their own organizations and the con- 
tractor operates similarly, there is a great mis- 
conception about the contract’s value: main- 
taining its configuration, and using it as a 
mechanism to communicate and control work. 
Every project team leader should be familiar 
with the contents of the contract, for it will en- 
able them to maintain a fair and equitable po- 
sition on many issues that will arise during 
project performance. Insist on compliance 
with the contract and initiate contract 
changes when there is a legitimate addition, 
subtraction, or change to be made. 

Communicate with Your Customer. The 
project team is both a supplier and a customer. 
It is very important that the team recognize 
this dual role. Too often I have seen the team 
consider its customers (customers are both the 
next level up in the project chain of command, 
and those organizations that significantly 
drive project requirements and funding) as en- 
emies rather than friends. During the course 
of a long-term project, the information flow is 
virtually the only product that will assure 
your customer that the project is on track. 
Making this flow effective will also produce 
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understanding of the external environment 
and its dynamics, which, in turn, will generate 
better decisions. An open, honest, and timely 
information flow among the project team, cus- 
tomers, and suppliers is a key ingredient of 
project success. 

Conclusion 


I have discussed what I believe are some es- 
sential principles in effective project manage- 
ment. There is no compromise to quality; 
proper requirements are a solid foundation; 
things will change; committed people make 
the difference; and communication of relevant 
information will keep a team on course. 


Project management, especially as it has de- 
veloped through NASA’s large-scale successes, 
is an extremely rewarding field. It enables 
each of us to take part and direct a portion of 
this nation’s progress. In the project manager 
role, we take on considerable responsibility, 
for we are accountable for the use of very valu- 
able assets. It is our job to ensure delivery of a 
system with the required performance, at or 
before the planned time, and within cost lim- 
its. Many skills are required and tools needed 
to be an effective project manager. Today, the 
task is being made both a little easier with im- 
provements in communication media and si- 
multaneously harder within our "fishbowl” 
environment. Building on past success and 
learning from mistakes are important. 
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Basically, project and systems management is 
nothing new. It is axiomatic that since the 
dawn of history there have been groups of hu- 
man beings trying to achieve a common goal 
within a certain time span and with available 
resources. These project-oriented groups were 
immediately confronted with the problems of 
organizing and managing such efforts and re- 
sources in order to reach their goal on time 
and with minimum expenditure. In modern 
times we call the educational approach to such 
an undertaking "Project and Systems Manage- 
ment.” Large projects of a scientific and tech- 
nical nature generally involve: 

• A multitude of government agencies, in- 
dustrial firms and other organizations, 
sometimes on an international basis; 

• Funds in the multimillion to billion dollar 
category; 

• Complex technology sometimes reaching 
beyond the state of the art; 

• Large forces of scientists, engineers, tech- 
nicians and administrative personnel; and 

• Construction of extensive and highly spe- 
cialized facilities. 

This type of project became more and more 
common in this century and especially in re- 
cent decades to solve problems of national and 
worldwide importance, to pursue large-scale 
scientific endeavors, to meet the needs created 
by a rapidly expanding world population, or to 


achieve other goals. It soon became evident 
that such projects, of great magnitude and 
complexity, had to be considered under the 
overall "systems” point of view continuously 
during execution. The alternative to such a 
concept leads inevitably to non-optimal tech- 
nical solutions, cost overruns, and schedule 
slippages which would occur to the embarrass- 
ment of the responsible country, agency or 
firm. Therefore, terms like "Systems Manage- 
ment,” "Systems Engineering,” "Systems 
Planning,” etc., were introduced to describe 
the systems aspects that had been emphasized 
as an inescapable necessity. 

The management scheme that was developed 
and applied to the Apollo Program, a complex 
and technologically difficult program, is par- 
ticularly interesting. It is now well-known 
that the technical complexities and the pio- 
neering nature of this unprecedented under- 
taking were finally very successful, but the 
program was also accompanied by shortcom- 
ings, setbacks, and deficiencies during its ex- 
ecution — all of which challenged the manage- 
ment system. It soon became clear that the 
project management had to be extremely flexi- 
ble and capable of meeting unforeseen de- 
mands. It was also apparent that determina- 
tion, resoluteness and faith would be vital if 
the goal were to be achieved. 

To assure success of the Apollo Program, the 
first order of business was to minimize techni- 
cal risks or actually mission risks as much as 
possible and, at the same time, to keep closely 
to the time schedule. Because of the rigid de- 
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mands of this time schedule, it was necessary 
wherever possible to engage in parallel rather 
than consecutive developments. In order to re- 
duce technical risks, backup solutions in cer- 
tain unprecedented areas, sometimes down to 
the component level, had to be concurrently 
pursued. For example, all possible abort 
schemes one could think of were considered 
and designed for, to provide the maximum pos- 
sible safety. This concept is expensive, but it 
was accepted as an alternative to increased 
possibility of failure of the whole program. 

Tight budget control and highest economy in 
expenditure were, of course, strong require- 
ments but were subordinate to technical needs 
and the demands of the time schedule. Natu- 
rally, there is a trade-off between acceptable 
technical risks or product quality, time sched- 
ule and project cost. For instance, to eliminate 
the technical risk problem, frequently undue 
quality control or overtesting of hardware is 
applied which delays schedules and makes 
costs skyrocket. If the program management 
permits faulty components to enter the system 
- due to lack of quality control and testing - 
the components would only be detected in 
overall checkouts. And finally, unrealistically 
short time schedules endanger the quality of 
the product and cost control, whereas long, 
drawn-out time plans increase total project 
cost. 

In summary, there has to be an optimum bal- 
ance among technical performance, time 
schedule and cost. In the Apollo Program, this 
balance was deliberately shifted toward tech- 
nical performance and time schedule. Depend- 
ing on the nature of a project, such a balance 
could as well shift in the direction of economy 
and trade-in on technical performance. 

Short Summary of the Apollo Program 

For a better understanding of the manage- 
ment concept and of the problems confronting 
management, a brief history of the Apollo Pro- 


gram might be helpful. The mission as stated 
by the President of the United States and ap- 
proved by the Congress was to land a man on 
the Moon in the decade of the 1960s and return 
him safely to Earth. During the excursion, sci- 
entific experiments were to be conducted for 
exploration of the Moon and its origin in order 
to provide a better understanding of the possi- 
ble age and creation of the solar system. Also, 
other corollary research was to be undertaken. 

It has been common practice in government 
circles to use the term "program” to describe a 
large, multimillion dollar undertaking. With- 
in such a program, major elements have com- 
monly been referred to as "projects.” Thus, the 
lunar program in its entirety is referred to as 
"Apollo.” The Saturn launch vehicle, an ele- 
ment of the total program, would properly be 
called a project. It is my understanding that in 
commercial or industrial practice, the term 
"project” is generally used rather than "pro- 
gram.” For consistency, I shall use the term 
"program” for Apollo. 

The program was started in 1961. Early snap- 
shot estimates of cost were between $20 billion 
and $40 billion. After the program was laid 
out and firmly established, detailed calcula- 
tions brought the estimates closer to $20 bil- 
lion. Of this money, approximately 90 percent 
was spent in industry and 10 percent in gov- 
ernment operations. During the peak of the 
effort, approximately 12,000 government em- 
ployees and approximately 300,000 people in 
industry were employed. An investment of ap- 
proximately $2.5 billion in new construction of 
facilities was made all over the United States 
at industry and government installations. 
These included the build-up of new govern- 
ment Centers; namely, the Manned Spacecraft 
Center at Houston, Texas, and the Kennedy 
Space Center at Cape Canaveral, Florida. It 
also comprised an expansion of the Marshall 
Space Flight Center at Huntsville, Alabama, 
including subsidiaries for production and test- 
ing at other locations. 
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The total program consisted of the develop- 
ment and production of three types of launch 
vehicles; namely, Saturn, Saturn IB and Sat- 
urn V, and two types of spacecraft: a Com- 
mand Service Module and a Lunar Landing 
Module. As a precursor, the Gemini Program 
was introduced. The special objectives were to 
improve life support systems and to develop 
docking processes, extravehicular activities 
and other techniques for Apollo. 

Basic Principles Established in the 
Apollo Program Management System 

After agreement had been reached on the 
method for traveling to the Moon and landing, 
and departure from the lunar surface for re- 
turn to Earth, attention was turned toward es- 
tablishing certain management basics to as- 
sure effective program execution. The size and 
complexity of the effort added an increased im- 
portance to such considerations. 

First of all, there had to be "a superior plan- 
ning effort.” I venture to state that, without 
diligent planning - especially systems plan- 
ning - right from the start, any project is 
doomed sooner or later to run into most serious 
difficulties. To recover from such planning 
failure costs large sums of money and time de- 
lays. It also brings a program into technical 
trouble which, as history has shown, could re- 
sult even in cancellation. 

Solid planning starts with master plans on 
hardware, software, and overall systems as to 
technical approaches; resources such as facili- 
ties, manpower and funds; and, finally, sched- 
ules. Important are detailed breakdowns of 
the overall job and the system into subsystems 
and what is called in Apollo "work packages.” 
Then come the significant areas of planning of 
contracts and the contractor structure. This 
results in the determination of which pack- 
ages to assign to prime contractors and, in spe- 
cial cases, to major subcontractors who are to 
be selected by Source Evaluation Boards. This 


selection is based on work statements, Re- 
quests for Proposals, and their submissions. 
The selected prime contractors have to be in- 
corporated immediately into the planning ac- 
tivity. 

It is strange that so few otherwise gifted man- 
agers and engineers do not see the significance 
and the great importance of proper planning. 
Such seems to be the case, however. It ex- 
plains at least partially why we had great dif- 
ficulties in finding technical experts who un- 
derstood the value of planning. For the mili- 
tary, strategic planning is a matter of course. 
The same is true for any commercial under- 
taking where to neglect planning is to court 
bankruptcy. Why it is so hard to introduce 
proper planning into project and system man- 
agement of projects of a more scientific nature 
is perplexing to me. 

For success in any program or project, large or 
small, I consider it a dominant principle that 
management must have what we in the Apollo 
Program called "visibility.” This means that 
the management at all levels should know al- 
most in "real time” what is going on in the pro- 
gram: technical occurrences, schedule 
progress or delays, and financial status. From 
the outset of the program, proper and effective 
channels and ways of communication have to 
be established on the government side be- 
tween upper and lower echelons of manage- 
ment. Similarly, the prime contractors must 
provide equally effective channels down to 
their respective subcontractors. Such an infor- 
mation system should not only depict the past 
and present status, but, more importantly, 
should also enable management - again on all 
levels - to predict trends in the progression of 
the program. The prediction of trends for some 
months ahead, or even longer, is vital for tak- 
ing corrective steps before the program runs 
into impediments. The capability of manage- 
ment to foretell trouble and thus avoid it by 
appropriate actions was one of the major cor- 
nerstones of the Apollo success. 
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Next of importance was the establishment of 
certain "review milestones,” that is, scheduled 
dates of management review between govern- 
ment and prime contractors. Such reviews 
are, for instance, in a chronological sequence: 


Program Requirements Review PRR 

Preliminary Design Review PDR 

Critical Design Review CDR 

Design Certification Review DCR 

Pre-Delivery Turn-Over Review PDTR 

Flight Readiness Review FRR 

Countdown Demonstration 
Test and its review CDDT 


Figure 1 shows these reviews over the life of a 
program and the process applied to lead to a 
particular launching. Some indication of tim- 
ing of the review span may be gained by not- 


ing that the Countdown Demonstration Test 
and review preceded an Apollo launching by 
five weeks. 

In the Apollo Program there were many more 
reviews beyond those shown. They all served 
to critically examine and assess the project 
status, to affirm the quality of the product and 
its reliability, and to assure systems safety. 
Every review resulted in protocolled action 
items. As the resolution of problems raised at 
each of the reviews was completed, the con- 
tractor was authorized to go ahead with the 
next increment of the overall plan. 

Also employed as an important management 
tool was the PERT, or Program Evaluation 
and Review Technique. This well-known ap- 
proach needs no further elaboration. 
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Figure 1 . The Apollo Review Process. 
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Configuration control was another necessary 
management tool in the Apollo Program. This 
control scheme assured that: 

• The contractor followed acceptable draw- 
ing room practice as to procedure and disci- 
pline; 

• Design intentions were carried through 
manufacturing; 

• Only mandatory changes were approved; 

• The exact configuration, known down to 
the most minute detail, was delivered to 
the launching site; and 

• Failures or unsuitable hardware or materi- 
al could be traced down to the point of ori- 
gin. Apollo management called this "trace- 
ability.” 

Configuration control carried out in a strict 
sense is very expensive. It is, therefore, vital 
that these controls not be overdone and that 
they are wisely introduced to prime contrac- 
tors and subcontractors. 

Application of the penetration principle did 
not stop at the government-contractor bound- 
ary. Instead, it permeated through the con- 
tractor organization to the subcontractor 
structure. Spawned by this approach, im- 
proved failure analysis appeared throughout 
the system; in-process inspection was main- 
tained at a high level; and receiving inspection 
techniques and effectiveness were improved, 
among other benefits. 

The application of the penetration approach 
resulted in a a vastly improved and effective 
communication channel with a host of side 
benefits. So while it might on the surface ap- 
pear as an invasion of prerogative by the gov- 
ernment, actually penetration should be look- 
ed upon as the close interaction of highly dedi- 
cated, competent technical and scientific per- 
sonnel, all motivated by the impressive chal- 


lenge of a huge complex program, no matter 
whether they are government or contractor 
employees. Most instrumental in this 
government-contractor relationship was the 
establishment of resident personnel in the 
prime contractor plants. 

Another point basic to the management of the 
programs involves "contracting principles.” 
Early in the Apollo Program, cost-plus-fixed- 
fee contracts were employed. The reason for 
using this contracting approach is rooted in 
the uncertainties of effective, close pricing in 
such a program with its many unknowns. 
Subsequently, the incentive fee contract was 
introduced. Essentially the fee applied con- 
sisted of two parts, one a base fee of modest 
proportions and the second a scaled or incen- 
tive segment. As the name implies, the 
amount of incentive fee awarded to a contrac- 
tor in addition to the base fee was a direct re- 
sult of success in meeting program product re- 
quirements for performance, cost, and time 
schedule. The incentive fee contract lends it- 
self well to hardware contracts with reason- 
able, well-determined milestones, cost levels 
and schedule. (I should point out here that in 
several cases where contractors were exper- 
iencing troubles, effective management prac- 
tice was considered in adjudging fee.) 

In contract arrangements where the param- 
eters are not easily distinguished in advance, 
a variation known as award fee contracting is 
used. The contractor is adjudged on a more 
general basis; support service or engineering 
service contracts fall into this category. It 
may be seen rather clearly that this method of 
contracting is motivational in nature, thus ful- 
filling an important management require- 
ment cited earlier. 

Beyond the contracting device, additional and 
continuing motivational or inspirational tech- 
niques were used. While the award and incen- 
tive fee channel reached the interior of an or- 
ganization through conventional management 
channels, there were others that appealed di- 
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rectly to the workforce of contractor and sub- 
contractor. Located in the program and major 
project offices was a Manned Flight Aware- 
ness Office. The function of this office was to 
keep all program workers aware of the need 
for success by each individual. This was an ef- 
fective technique that became tangible when 
merit awards and recognition were issued. 

There are a number of other pertinent princi- 
ples upon which the effectiveness of program 
management depends. Although they apply in 
other management schemes and in programs 
where the government is not involved, in a 
program-oriented structure, they are critical: 

• Organize and motivate to achieve effective 
high morale in the workforce; 

• Delegate authority clearly, concisely and 
positively to achieve timely decisions; 

• Apply innovative concepts and techniques 
courageously; 

• Keep objectives pointed toward the goal; 

• Require continuing study and application 
of the systems engineering approach; and 

• Relate actions to schedule and to budget 
continuously. 

The Apollo Management System 

In the actual managerial arrangement that 
used the principles I have mentioned to man- 
age the program throughout its life, we did 
not enjoy any measure of managerial "genius” 
in running our changing, dynamic organiza- 
tion. On the contrary, our management sys- 
tem evolved after some painful experiences in 
the early days of Apollo. In fact, at the begin- 
ning of the program in 1961, there was no com- 
mon system in existence within the rather 
young National Aeronautics and Space Ad- 
ministration. Then as the program gathered 
headway and matured, the management sys- 


tem became better defined, changing as neces- 
sary to keep pace with unfolding events. Early 
it was learned that in the environment of a big 
development project, there can be no static 
system. Change and evolution are inevitable. 

Figure 2 is what we called the "Apollo Pro- 
gram Trend Chart.” Management used this 
chart to follow the progress of every major 
component such as rocket stages, engines, 
spacecraft, etc. In this case it was employed as 
a master chart for predicting the landing date 
on the Moon. On the ordinate you see the 
planned launch date and on the abscissa the 
reporting date or the status. This visibility 
scheme was introduced in 1965 after the first 
lunar landing date, originally planned for the 
first half of 1967, slipped several times. 

By 1962, after the decision on how to go to the 
Moon and after the introduction of the Gemini 
Project, the Apollo Program began to take 
shape rapidly. Budgets had increased deci- 
sively. American aerospace industries and 
universities were significantly expanding 
their involvement. Also, of course, by this 
time three sizable Centers were involved to ca- 
pacity in the technical and managerial de- 
mands of their respective Apollo assignments. 
This involved multimillion dollar projects at 
each — the command module, service module 
and lunar module at Houston; three stages 
and an instrument unit at the Marshall Space 
Flight Center in Huntsville; and assembly and 
launch operations at Cape Kennedy. Coupled 
with the national involvement of the industri- 
al complex, the need for innovative overall 
management was clear. For this and other 
reasons, the Apollo Program management of- 
fice in Washington, and the project manage- 
ment offices at the three field Centers, were 
thus restructured and strengthened to fulfill 
the vital role of the overall integration and 
management of all contractor, field Center 
and university efforts. 

Figure 3 shows how the Apollo Program Office 
was placed in the complex of the Manned 
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REPORT DATE 


Figure 2. The Apollo Program T rend Chart. 

Space Flight organization of NASA Headquar- 
ters. Note that the Apollo Program box ap- 
pears in the NASA command structure just as 
any functional or institutional segment would 
appear, reporting to the Associate Administra- 
tor, who, in turn, reports directly to the NASA 
Administrator. 

Figure 4 depicts the Apollo Program manage- 
ment structure. Some of its features require 
special attention in order to thoroughly under- 
stand the actual arrangement. 

The Associate Administrator for Manned 
Space Flight at the same time chaired the 
Management Council. Its membership con- 
sisted of the Associate Administrator’s depu- 
ties and the field Center directors with their 


deputies. Acting in a directive role, the Asso- 
ciate Administrator passed instructions to the 
field Center or to the Apollo Program Office. 
In turn, the Center director, through member- 
ship on the Management Council, had a direct 
voice in shaping the program direction which 
comes to the Center for execution. The Coun- 
cil met once a month or at the direction of the 
Associate Administrator, its Chairman. At 
these meetings, the Apollo Program Director 
in Washington and the project managers of the 
field Centers reported to the Council. The pro- 
ject managers included the Saturn V Manager 
from the Marshall Space Flight Center, the 
Apollo Spacecraft Manager from the Manned 
Spacecraft Center, and the Manager for Apollo 
launch preparation at the Kennedy Space 
Center. 
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Figure 3. Manned Space Flight Organization, 1968. 


The topic of these presentations covered, 
among others, the following principal areas: 

• Where did the money go and can we man- 
age with the allotted funds remaining? 

• What planned tasks have been accom- 
plished and can we meet the projected 
schedule? 

• What are our major technical and program- 
matic problems and what previously un- 
foreseen actions must be taken to overcome 
them? 

• What are our motivational problems? 

The Design Certification Review (DCR) was 
part of the Management Council meetings and 
the certification was signed by the Chairman 
and the three Center directors. 


Five organizational segments reported direct- 
ly to the Apollo Program Office. They were 
the major units through which the program di- 
rector managed the program. Corresponding 
to this organization was the field Center’s or- 
ganization with exactly the same segments. 
The names of the boxes are self-explanatory. 
A similar organizational structure was set up 
at the prime contractors, to the extent that 
such was necessary. 

Figure 5 indicates the manner in which the 
contractors, prime and sub, may relate to a 
project. The diagram in this case pertains to 
the Saturn Project at the Marshall Space 
Flight Center and the corresponding contrac- 
tor structure. Of particular interest here is 
the relationship between the institutional 
technical capability and the project manager 
on the one hand, and this capability and the 
contractor on the other. 
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Figure 4. Apollo! Saturn Program Management. 


The ready access that the project director had 
to the engineering expertise of the Center was 
of particular importance in maintaining real- 
time project visibility and control. For maxi- 
mum effectiveness, the institutional capabil- 
ity must respond to specific requests and 
maintain continuing surveillance, thus expos- 
ing unsatisfactory technical trends early 
enough to allow preventive measures. As an 
additional contribution, the in-house technical 
capability may and frequently did respond to 
requests from the prime contractor. 

Other areas of the Apollo Program that were 
of great significance to the program manage- 
ment are: 

• The system logistics: that is, transporta- 
tion of hardware from manufacturer to 
launching site, supply of propellants, pres- 
surants, spare parts, etc.; 


• The safety and security system; 

• Astronaut training with all the training 
hardware and simulators; 

• The medical aspects of the expedition; 

• The organization and management of the 
scientific endeavor; 

• The determination of the landing sites on 
the Moon; 

• The ground organization and the world- 
wide network for tracking and data acqui- 
sition during a mission. Sixteen stations 
distributed around the Earth had to be op- 
erated, many in foreign countries; and 

• Finally, the planning of the mission opera- 
tion and the mission operation itself. 
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Figure 5. Contractor-Project Relationships. 


All these subjects comprise major activities 
which had to be integrated into an overall 
management system. In order to provide 
maximum control and visibility of the system 
and of all occurrences in the program, a sys- 
tem of control rooms was established. These 
rooms contained up-to-date information and 
displays and were located at the Apollo Pro- 
gram Director’s Office in Washington and at 
the three Manned Space Flight Centers and at 
each prime contractor. Each control room was 
equipped to permit conference calls between 
Headquarters and the Centers. This commu- 
nication system furnished a means for greatly 
accelerating the decision-making process. 

I should now like to explain the matter of inte- 
grating the project office, the functional ele- 
ments of the institutional organization, and 
the contractor. Three categories of concern 
emerge. First, there are the hardware, sys- 
tems and subsystems specialists who devote 
attention to the delivery of items that are tech- 
nically adequate and qualified for mission per- 


formance. Second, there are the specialists 
who approach the project from the point of 
view of controlling costs and schedules. As the 
third organizational element in the grouping, 
there is the on-site resident management of- 
fice. Staffing this latter element were special- 
ists located at the contractor’s facility to as- 
sure that project management interests were 
advanced and that decisions were made and 
implemented within the designated scope of 
authority of the resident group. 

This resident element proved to be a most im- 
portant link between government and contrac- 
tor activities. To expedite decisions, the resi- 
dent manager required functional support, 
which was provided by specialized, on-site con- 
tract administration and technical engineer- 
ing staff. These support personnel were as- 
signed from parent functional organizations of 
the responsible Center. Within well- 
established limits, these people could make de- 
cisions "on the spot” or commit the parent of- 
fice or function at the Center. The result was 
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to speed the project management process and 
to provide a dynamic interface with the con- 
tractor on a continuing day-to-day basis. It 
was in this relatively small unit that the rela- 
tionship of project management and functional 
discipline was most clearly mirrored; where 
the integration of technical and managerial 
personnel became most apparent. This unit 
also provided a mechanism for tempering the 
varying emphasis on government project and 
functional groups in the contractor organiza- 
tion. For example, the technical functions 
tend to strive primarily toward perfection to a 
degree that possibly inhibits adequate atten- 
tion to manufacturing and launch schedules or 
cost. The contractor could well be oriented to- 
ward schedule, costs and profits, whereas the 
project manager might weigh concern more 
heavily on schedule and costs. Through the of- 
fice of the resident manager, an automatic sys- 
tem of checks and balances developed to the 
end that each consideration received its appro- 
priate share of attention. 

Conclusion 

A number of the points I have raised offer a 
high potential for solving difficult problems. 
One of these is the technique of contractor pen- 
etration to obtain visibility. There is an un- 
derstandably strong desire on the part of in- 
dustry to take the control and the funding and 
to do the job with but minor government inter- 
vention. However, there have been too many 
cases of severe program impacts when this al- 
ternative to close contractor surveillance has 
been permitted. The restiveness that 
stemmed from such close control gradually 
dissipated early in the Apollo Program as the 
benefits accruing from the industry- 
government teams approach were revealed. 

In forming the project or program offices, it is 
clear that the manager must have control of 


competent technical and administrative staff 
in order to conduct activities efficiently. In the 
event that such competence is not available, a 
vital principle would be jeopardized — that of 
responsibility requiring adequate authority. 
Competent staff members must be drawn from 
the functionally oriented disciplines. 

Yet another aspect of personnel concerns the 
disposition of people upon termination or com- 
pletion of a program. It is not sufficient to rel- 
egate them to positions formerly held, particu- 
larly in the case of technical persons. If a new 
program is forthcoming, the problem is eased 
somewhat, although it is highly likely that re- 
training or refresher education will be re- 
quired. In any event, the transition from pro- 
gram management status back to a technical 
activity in a laboratory can indeed be traumat- 
ic. It is here that the institutional leadership 
must be asserted on the highest plane. 

While centralized program management has 
many values, of prime importance is the as- 
signment of all responsibility to single organi- 
zational management structures, pyramiding 
into a single strong personality. This prevents 
fragmenting vital responsibility among nu- 
merous individuals with subsequent loss in 
time, money, manpower and technical 
progress. Of course with the responsibility, 
the manager must have commensurate au- 
thority to resolve technical, financial, produc- 
tion and other problems that otherwise re- 
quire coordination and approval in separate 
channels at different echelons. And the man- 
ager must have clear, concise communications 
flowing in all directions. 

With these tools, program management can 
apply all the capabilities — technological, so- 
ciological, economic, or whatever - to any pro- 
ject and systems problem, however large or 
complex it might be. 
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NASA Administrator James E. Webb had 
been in office only three months before Presi- 
dent Kennedy announced his decision for a 
manned lunar landing. Webb was in charge of 
a rapid acceleration in the NASA budget and 
staff. While the program build-up was under 
way, Webb instigated a series of internal man- 
agement analyses and reviews, some of which 
were extensions of initiatives taken by his pre- 
decessor. One of the major problem areas first 
explored was the Headquarters-Field Center 
relationship, one which has been studied and 
reorganized almost continuously ever since. 

During NASA’s first three years, the field 
Centers reported to Headquarters program di- 
rectors rather than to general management. 
There were two major weaknesses in this sys- 
tem. The subordination of Center directors to 
Headquarters program directors tended to cre- 
ate a gulf between the field and Headquarters. 
Secondly, the Headquarters program offices 
tended to be more narrowly focused than the 
more multi-purpose field Centers, and there 
was a mismatch in the missions and institu- 
tional interests of the various field Centers 
and their respective program offices in Wash- 
ington. 

In November 1961, the first of many subse- 
quent reorganizations was authorized, putting 
the field Centers directly under the Associate 
Administrator, Robert C. Seamans, Jr., who 
was later to become Air Force Secretary. The 
field Centers continued to receive specific pro- 
gram direction from the program offices, but 
were no longer subordinate to the program As- 


sociate Administrators. Earlier in his first 
year, Webb had authorized another major re- 
organization, establishing a new Office of Pro- 
grams and an Office of Administration based 
on a unit previously called the Office of Busi- 
ness Administration. The Office of Programs 
was responsible for integrating NASA’s pro- 
gram planning, facilities coordination, man- 
agement planning, resources programming 
and project reviews. As a means of exercising 
this function, the office established the Pro- 
gram Approval Document (PAD) system to 
govern the process of Headquarters review of 
specific programs. This new office and the Of- 
fice of Administration both reported to Robert 
Seamans. 

The 1961 reorganization fell short of expecta- 
tions. Three reasons attributed to the failure 
were: 1) the tendency of the new structure to 
create a "free-for-all” between the field Cen- 
ters and Headquarters, 2) the undermining of 
the authority of Headquarters program direc- 
tors to give direction over anything but specif- 
ic, discrete projects, and 3) the imposition of a 
crushing overload of responsibilities on a sin- 
gle Associate Administrator, Robert Seamans. 
Although the 1961 reorganization had served 
to remind Centers that NASA had a central 
purpose to which all local interests were secon- 
dary, it could not be maintained as a perma- 
nent arrangement. 

In November 1963, the structure reverted 
back to one in which field Centers reported to 
the Headquarters program office responsible 
for their primary program activities. As Webb 
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observed several years later, the purpose of 
the 1963 reorganization was to emphasize that 
a Headquarters program director, newly des- 
ignated as an "Associate Administrator,” was 
"a guy running his show . . . and that he ought 
to think of himself as nearly as possible doing 
the total job. He had to present his program to 
Congress he wasn’t just an internal manager. 
For his area he had almost as broad responsi- 
bility as the Administrator.”! 

Nevertheless, important aspects of Seamans’ 
role as "general manager” remained un- 
changed. The program Associate Administra- 
tors continued to meet regularly with him, and 
he continued to oversee the various internal 
management systems such as the PAD pro- 
cess. The decision to switch the Field Center- 
Headquarters relationship back to what had 
existed only two years before illustrates 
Webb’s belief in the importance of flexibility 
and adaptability. In Space Age Management: 
The Large-scale Approach , a volume based on 
his Columbia-McKinsey lectures delivered in 
1968, Webb wrote as follows: "Our constant 
effort has been to obtain a sufficient real-time 
feedback from the fastest-moving parts of our 
substantive and administrative activities to 
enable us to alter our course as needed. We 
have sought patterns of organization and ad- 
ministration that facilitated fast reaction 
times to signals of incipient failure or emerg- 
ing opportunity.” 2 

What Webb recognized as an essential part of 
the ethos of NASA was the need for a continu- 
ing process of adjustment and adaptation to 
dynamics of change both within and outside 
the agency. He saw that NASA could not be 
governed by the old-style principles of public 
administration which sought to assure stabil- 
ity and order within a rigid hierarchical 
framework. To accommodate the fast-moving 
scientific and technological projects for which 
NASA provided a home, NASA would have to 
stay loose. The components of the organiza- 
tion: the field Centers and Headquarters; the 
program and project offices imposed on a ma- 


trix organizational structure; the complex of 
in-house management; and the much greater 
corpus of outside contractors -- this vast array 
of disparate parts could never be expected to 
become a stable and harmonious entity. In an 
unpredictable and sometimes turbulent envi- 
ronment, Webb recognized a need to maintain 
a desired level of disequilibrium. 

This philosophical approach has been accepted 
within NASA throughout the post-Webb era, 
but with varying degrees of commitment. 
Much of NASA’s subsequent organizational 
history has evolved around the weighing of 
tradeoffs between the risk-taking, free- 
wheeling management style, and the search 
for more traditional values of order, continuity 
and stability. 

Centralization versus Decentralization 

The search for the best organizational pattern 
has also entailed a continuing quest for the 
best blend of centralization and decentraliza- 
tion. Several issues have been critical to the 
structure of the reporting relationships be- 
tween the field and Headquarters. 

1. How to maintain the desired degree of 
autonomy and independent initiative at 
the field Center level. 

2. How to assure that the Headquarters pro- 
gram Associate Administrators exercise 
adequate control over their respective pro- 
grams without engaging in "micro- 
management.” 

3. How to provide for adequate communica- 
tions between the Administrator and field 
Center directors without overwhelming the 
Administrator or undercutting the pro- 
gram Associate Administrator. 

4. How to find an individual with the right 
personality to serve in the Headquarters 
office to which the field Centers report. 
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Experience with the several types of reporting 
relationships suggests that there is no single 
"right” way to set them up. What works at one 
time may not necessarily work at another. 
The arrangement should be responsive to the 
management imperatives of the contemporary 
environment. In any case, the success of the 
total complex of reporting relationships de- 
pends on the crossfeed of significant and 
meaningful information among those having a 
"need to know” and the timely upward flow of 
the important information to whomever is re- 
sponsible for the agency’s general manage- 
ment. 

In the early days of NASA, the field Centers 
tended to have more discrete roles and thus to 
work only or mostly on programs falling under 
a single Headquarters program office. There 
was an obvious logic in clustering groups of 
Centers under the several program offices at 
Headquarters. Over the years the field Cen- 
ters, each seeking to build capability to com- 
pete for future projects, expanded their respec- 
tive areas of competence. At the same time, as 
the dimensions of the larger manned flight 
programs such as the Shuttle grew, the num- 
ber of Centers working on a single program in- 
creased correspondingly. Thus a new configu- 
ration evolved in which most of the Centers 
were working on programs falling under more 
than one Headquarters program office. 

Personalities and Personal Relations 

The question of personality cited above is a 
crucially important — some would say the 
most important — factor in determining how 
well the Headquarters-Field Center reporting 
relationship works. Obviously it is essential 
that the individual to whom the Center direc- 
tors report in Headquarters be someone in 
whom they can place their confidence. The job 
calls for a rare combination of experience and 
talent — including an ability to understand the 
Center directors and to represent them in an 
even-handed way — and a toughness in imple- 
menting sometimes unwelcome decisions. 


The relationships between Headquarters and 
the field reflect in large measure the chemis- 
try existing among the personalities of the Ad- 
ministrator, the Deputy, the Associate Admin- 
istrators for programs, and Center directors. 
Ideally, all these players should fit together as 
a closely knit and mutually supportive team. 
They should be able to understand each others’ 
needs and subordinate the goals of their re- 
spective positions and organizations to the 
broader goals of the agency. 

Strength Through Diversity 

Since the real world is, in fact, far from the 
ideal, a state of such harmony is always elu- 
sive. People in Washington and people in the 
field can never have the same perspectives and 
values. The Washington outlook is dominated 
by the power politics of the nation’s capital 
and the struggle to maintain NASA’s place in 
the federal establishment. Center outlooks 
are more oriented to specific research and de- 
velopment tasks to be accomplished. More- 
over, from Center to Center there is a built-in 
rivalry. Each Center nourishes an absolute 
conviction that it is the best of the lot. Each 
Center is hard at work to make its own place 
strong and secure in whatever lies ahead for 
NASA. No Center is willing to reveal its en- 
tire hand to other Centers or, for that matter, 
to Headquarters. Nevertheless, Centers can 
and do cooperate effectively on agency pro- 
grams and projects. In the process, they share 
facilities, people, and ideas. Institutional loy- 
alties, however, tend for the most part to stay 
fixed. 

Thus NASA is significantly different from 
many large decentralized organizations in ei- 
ther the public or private sector. Compared 
with the military establishment, for example, 
NASA often appears to resemble the collection 
of military services operating with consider- 
able rivalry under the Department of Defense 
rather than a single military service. Indeed, 
the competition among the Centers is mostly a 
positive force spurring each Center to excel in 
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comparison with its peers. In the private sec- 
tor the closest analogy would be a loosely-knit 
conglomerate with autonomous profit centers 
rather than a fully integrated single-line com- 
pany. 

In the case of either the public or the private 
analogy, all the elements of the organization 
share common goals but may differ sharply on 
the means for reaching those ends. The job of 
top management is to see that the best means 
are selected out of the competing ideas ad- 
vanced by the various contenders in the orga- 
nization. The NASA Administrator must at- 
tend to a great deal of advice, often conflicting, 
from contractors, the scientific community, 
and the numerous NASA advisory bodies. The 
Administrator’s task is to maintain the U.S. 
position of strength in our aeronautics and 
space programs, building on the diversity of 
policies, programs and resources over which 
varying degrees of control are exercised. 

Once an idea has prevailed in the internal 
competition among all the technical and pro- 
fessional experts, the Administrator must sell 
the idea to those who hold the purse strings. 
Thus a NASA Administrator will be judged in 
large measure by success or failure in persuad- 
ing the President, the Office of Management 
and Budget, and the Congress which programs 
will best support the aeronautical research 
and space interests of the nation. 

The Triumvirate 

Another hallmark of Webb’s administration 
was his acceptance of the concept of shared 
decision-making at the top. We have noted the 
important role played by Seamans as an inter- 
nal manager. Hugh L. Dryden, who had for- 
merly headed the National Advisory Commit- 
tee for Aeronautics and served as NASA Depu- 
ty Administrator under Glennan, had re- 
mained in the deputy position under Webb. 
Dryden was a highly respected aerospace sci- 
entist with a vast network of connections 
throughout the scientific community. 


During the years until Dryden’s death in 1965, 
the three top leaders of NASA — Webb, Dry- 
den, and Seamans — formed a triumvirate in 
which all three worked as a team in every 
sense of the word. Webb insisted that each 
was to be a full-scale participant in adminis- 
trative as well as substantive decisions. As 
James Beggs noted in the inaugural lecture of 
the National Academy of Public Administra- 
tion’s James E. Webb Fund for Excellence in 
Public Administration: 

"It was agreed that in policy and prac- 
tice no one of the three would act to do 
violence to the strongly-held views of 
the other two. The three were commit- 
ted to ensure that all of NASA’s lead- 
ership needs were considered and met 
at all levels.” 

Webb himself described the three-man rela- 
tionship as one which intentionally bound the 
three men in "hoops of iron.” A major applica- 
tion of this policy was a process requiring that 
all procurement decisions over $5 million be 
made by all three men. They reviewed the rec- 
ommendations of a technical/managerial team 
representing the most informed thinking on 
any individual procurement up to their level. 
Each final selection was made by the top three 
executives. 3 

Seeking Outside Advice 

One of Webb’s guiding principles was to 
spread the toughest problems over the largest 
possible number of capable minds. As the 
member of the triumverate who served as "Mr. 
Outside,” Webb was especially interested in 
seeking outside advice. Nearly ninety cents 
out of every NASA budget dollar was spent 
outside the agency, mainly in contracts with 
the aerospace industry, which provided a ma- 
jor source of advise on engineering and techni- 
cal questions. Webb also fostered an imposing 
network of university and academic relation- 
ships. Through the Sustaining University 
Program initiated by Webb in 1961, NASA 
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over the next decade channeled more than 
$100 million to academic institutions in sup- 
port of research and the doctoral programs of 
more than 5,000 scientists and engineers. An 
additional $42 million was channeled to uni- 
versities for construction of research facilities 
on 31 campuses. Webb was thus able to tap 
into the best thinking of industry, the aca- 
demic community, and the able people whom 
he gathered together within the agency. He 
extensively used management consultant 
teams and individuals, and the many special 
advisory committees and panels set up by the 
National Academy of Sciences. 

Because of his special interest in administra- 
tion and management, Webb was elected 
President of the American Society for Public 
Administration (ASPA) in 1966. He soon 


came to see the need for an organization which 
could perform an equivalent role in public ad- 
ministration to that of the National Academy 
of Sciences in its field. He felt that NASA and 
other government agencies should have access 
to a source of trusted counsel that could give 
advice on questions pertaining to manage- 
ment and administration. Accordingly, Webb 
organized those who had preceded him as 
ASPA presidents to become the founders of the 
National Academy of Public Administration. 

NASA provided the initial funds that permit- 
ted the academy to open its doors while con- 
ducting some initial studies of NASA manage- 
ment. The granting of a federal charter to the 
Academy in 1984 represented a major mile- 
stone in the fulfillment of Webb’s vision 17 
years earlier. 
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Reorganization: A NASA Management 
Refrain 

As noted in the earlier discussion of the 
reorganization during the Webb admini- 
stration, the Field Center-Headquarters 
reporting relationship has undergone many 
permutations throughout the agency’s history. 

In the spring of 1974, Dr. Fletcher and his col- 
leagues began to believe that in a period of 
budget reduction such as NASA was exper- 
iencing, the Headquarters-Field Center re- 
porting alignment was no longer responsive to 
overall agency needs. Accordingly, another 
major reorganization was implemented, estab- 
lishing for the first time an Office of Associate 
Administrator for Center Operations. Two 
subsidiary offices, one for Institutional Man- 
agement and a second for Headquarters Ad- 
ministration, were set up under this new Asso- 
ciate Administrator.4 Again, as in the period 
from 1961 to 1963, the field Centers reported 
to a single Headquarters office. The new Of- 
fice of Institutional Management, responsible 
for agency-wide institutional management, 
was a response to concern in the field about in- 
adequate attention in Headquarters program 
offices to institutional resources, namely the 
equipment, facilities, and personnel required 
to sustain the technical and scientific capabil- 
ity of the Centers. 5 

In his second year in office, Fletcher’s succes- 
sor, Dr. Robert A. Frosch, found that the Field 
Center-Headquarters reporting relationship 
put into effect four years earlier by Dr. Fletch- 
er was not working to the satisfaction of most 
of the key people involved. Frosch instituted a 
first-ever system in which all the Centers and 
all the program Associate Administrators re- 
ported directly to him. The new system gave 
the Center directors direct access to the Ad- 
ministrator, but it stretched the span of con- 
trol beyond what is generally regarded as rea- 
sonable limits. 


The fifth reorganization of the Headquarters- 
Field Center relationship was carried out by 
the next Administrator, James E. Beggs, who 
reinstated the system in which the field Cen- 
ters report in clusters to the program offices. 
This configuration ran into some of the same 
types of problems confronted in the past under 
similar arrangements. Each of the Centers 
worked for more than one program office. The 
Centers felt that too little concern was given 
by their respective program offices to the insti- 
tutional health of the Centers. Center direc- 
tors were not satisfied that the program offices 
represented their interests in Headquarters 
decision-making. Old refrains were being 
heard again and another reorganization ap- 
peared to be in the making. 

Looking Inside Today’s NASA 

(Note: Although this article was written in 
1985, some of the insights are applicable today. 
— Editor.) 

Today's NASA retains many of the same attri- 
butes that have distinguished the agency since 
its formation. Much of the management phi- 
losophy developed in the agency’s first ten 
years and articulated by James Webb still 
guides today’s management. The basic organi- 
zational structure, the high degree of auton- 
omy accorded to the field Centers, and the 
heavy reliance on contractors as the principal 
agents to do the work still remain as impor- 
tant features of the NASA modus operandi. 
Perhaps most remarkable [as of 1985] is the 
continuity of personnel. NASA has one of the 
lowest turnover rates of any federal agency. 
Most of NASA’s highly skilled technical and 
professional employees know that the excite- 
ment and challenge of their jobs cannot be 
matched elsewhere. Even though many of 
NASA’s senior staff have skills and talents 
that are readily marketable in the more high- 
ly paid private sector, they choose not to move. 


40 



NASA Organization Management from 1961 to 1965 


The negative side of this personnel profile is 
the fact that many NASA employees now ap- 
proaching retirement eligibility are likely to 
leave in a mass exodus over the next several 
years. This problem is compounded by a scar- 
city of potential leaders between the ages of 30 
and 40 — a gap caused by low recruiting levels 
in the cutback period of the 1970s. Recently, 
however, NASA has had great success in re- 
cruiting highly qualified college freshouts. 
The NASA mission still attracts topflight sci- 
entists, engineers, and technicians. 

Regardless of its recent success in attracting 
quality personnel, NASA suffers today from 
many of the same exigencies that afflict other 
departments and agencies of the federal gov- 
ernment. The environment for these federal 
organizations has been severely damaged by 
the anti-bureaucratic rhetoric so prominent in 
recent political campaigns and the excessive 
zeal of those seeking to gut the federal work- 
force. Equally damaging has been the vast ar- 
ray of rules and regulations, promulgated 
largely in response to Congressional pres- 
sures, that have resulted in tighter limits on 
the ability of government managers to man- 
age. 

The vigor and vitality of NASA in its early 
years came in large measure from the sense 
within NASA that the agency was its own 
master. Congress appropriated the money; 
NASA executed the program. The manage- 
ment of the agency was more than willing to 
assume responsibility and accountability for 
the expenditure of the public funds entrusted 
to it. 

Today's management climate is vastly differ- 
ent from that of NASA’s early years. Like oth- 
er federal agencies, NASA finds itself under 
the close scrutiny of numerous Congressional 
committees, each with its own particular 
agenda and priorities and each seeking infor- 
mation in more and more detail. With such in- 
formation the committees can carry out their 
oversight function to the point of what often 
appears as micro-management. 


A major instrument of congressional oversight 
is the General Accounting Office (GAO). Staff 
of GAO, working with the greatly expanded 
(some would say overblown) staff of the Con- 
gressional committees, are constantly looking 
over the shoulders of all federal managers. At 
the same time, the central agencies of the ex- 
ecutive branch -- the Office of Management 
and Budget, the Office of Personnel Manage- 
ment, and the General Services Administra- 
tion — have imposed layer upon layer of regu- 
lations resulting in increasingly centralized 
management systems. As a result, managers 
at all levels are forced to devote excessive 
amounts of their time and energies to the fil- 
ing of forms and writing of reports. In such ba- 
sic areas as personnel, procurement, travel, 
and budget management, managers find that 
they have only limited freedom of action. Dur- 
ing NASA's early days, decisions were made at 
all levels of management on a timely basis, 
but today's decision-making process moves 
more slowly and ponderously. Whereas key 
individuals or small groups took responsibility 
for decisions in the past, today that responsi- 
bility tends to be spread out among larger 
groups or committees. 6 

An inevitable result of having so many watch- 
dogs and so many centralized regulatory sys- 
tems is inhibiting initiative and the willing- 
ness to innovate or take risks. Instead of dele- 
gating responsibility to lower levels, each lev- 
el of management feels compelled to retain 
tighter controls and more decision-making au- 
thority. Thus NASA Headquarters program 
offices exercise what the field Centers regard 
as micro-management, and the working rela- 
tionship between the two levels is strained. At 
lower levels throughout the agency, managers 
are diverted from their principal tasks by the 
need to comply with the regulatory overload. 

Despite these negative forces working against 
good management, NASA stands out as one of 
the best run agencies in the federal establish- 
ment. The high standard of NASA perfor- 
mance owes much to the innate drive of NASA 
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personnel to strive for excellence. NASA’s 
workforce, by virtue of its high levels of educa- 
tion, training, and motivation, represents an 
elite corps. They take great personal pride in 
their participation in a program which is so 
highly visible and so much a symbol of Ameri- 
can leadership in science and technology. The 
continuing high level of job satisfaction in the 
agency ties directly into the fast-paced techni- 
cal challenges inherent in the lofty goals set 
out in the NASA charter and the commitment 
of space activities "to peaceful purposes for the 
benefit of all mankind.” 

While much has remained constant in the 
NASA physiognomy, significant change is un- 
der way in the nature of NASA’s mission. Un- 
til the era of the Shuttle, that mission consist- 
ed mainly of various scientific exploration and 
technology development programs of limited 
duration. As an R&D organization, NASA 
was by nature devoid of any operational role. 
The implicit prevailing assumption was that 
once a space science mission had been accom- 
plished, the results would be turned over to 
the scientific community for investigation. 
Likewise, in the aeronautics research area, 
findings were turned over either to potential 
commercial users or to the military establish- 
ment. The Space Shuttle and the Space Sta- 
tion, each being long-term operational enter- 
prises, pose a new set of questions with respect 
to the most appropriate institutional home. 

The question of the best institutional base for 
the Shuttle came up for discussion and analy- 
sis as the development phase got under way. 
In 1977, James Beggs, then Executive Vice 
President of General Dynamics, chaired a pan- 
el of the National Academy of Public Adminis- 


tration that considered various organizational 
alternatives for the Shuttle. The report of the 
panel concluded that unless and until the eco- 
nomics of the Shuttle provided a basis for at- 
tracting private investment, the best organi- 
zational alternative was to retain the Shuttle 
in NASA? 

In the eight years since that study was con- 
ducted, the prospects for turning the Shuttle 
into a net revenue producer have changed for 
the worse rather than for the better. Although 
many in NASA would welcome an opportunity 
to hand over the Shuttle to some other organi- 
zation in order to refocus NASA on its tradi- 
tional R&D tasks, there are no other appropri- 
ate alternatives in sight. 

Looking ahead to the point in the 1990s when 
the Space Station is scheduled to become oper- 
ational, it appears that a similar set of ques- 
tions will arise. Indeed, for as long as one can 
see clearly into the future, it seems that the 
NASA mission will include, in addition to the 
traditional time-limited R&D activities, a re- 
sponsibility for the maintenance of operating 
systems providing access to and a permanent 
manned presence in space. Six field Centers 
are now involved in the Space Station pro- 
gram. Such major changes under way in the 
mission of NASA will probably call for further 
agency-wide organizational adjustment and 
restructuring. 

— October 1985 

Edited and excerpted from sections o/WASA; The Vision 
and the Reality by Erasmus H. Kloman. National Acad- 
emy of Public Administration (GPO: 1986-491-574. 
40015). Used with permission. 
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Management and Budget Lessons 
The Space Shuttle Program 

by Humboldt C. Mandell, Jr., Ph.D 
Johnson Space Center 


After each major manned space program, the 
Johnson Space Center has conducted research, 
written histories, and analyzed management 
methods to scrutinize the past for weaknesses 
and mistakes that can be avoided in the fu- 
ture. These efforts have had three results: 

1. Some practices and weaknesses have 
been influenced and changed. 
Among specific lessons learned are the 
need for extended program definition 
phases, resistance to pressures to esti- 
mate costs on the low side, incorpora- 
tion of adequate cost reserves into the 
planning process, accurate initial esti- 
mates to provide program stability, and 
the increased involvement of NASA 
analysts in the prediction of program 
budgets. 

2. Some problems have continued be- 
cause the cultural acceptance of prac- 
tices has made them difficult to modify. 
For example, the lack of emphasis on 
the "budget year” throughout the man- 
ned space program contributed to budg- 
etary problems, but the practices have 
remained relatively unchanged from 
the Apollo program up to the present 
time. 

3. Some obvious problems are inherently a 
part of government program manage- 
ment systems and are beyond the ca- 
pability of any agency to influence. An 
example of this is the divided manage- 
ment responsibility, which has been a 
part of some large NASA programs, 


compromising the unity of command. 
In a political society, such compromises 
are a way of life and cannot be easily 
changed by the agency itself. 

Some reform of the NASA budget process has 
been called for by study groups, along with 
closer coupling of the design and cost estimat- 
ing processes, and improvement of perfor- 
mance management/measurement systems. 

Analysis of Previous Lessons Learned 

In 1971, at the beginning of the Space Shuttle 
Program, an extensive interview process was 
conducted at Johnson Space Center to deter- 
mine what management lessons had been 
learned by the aerospace industry which 
might help avoid problems in managing the 
Space Shuttle development. A structured set 
of interviews was conducted with senior man- 
agers of teams from the highest technology 
aeronautical programs then existing. These 
included the SR-71 Strategic Reconnaissance 
Aircraft of the United States Air Force (Cla- 
rence "Kelly” Johnson, Program Manager, 
Lockheed Aircraft Co.); the Boeing 700 series 
of aircraft (George Schairer, Vice President, 
R&D, Boeing Airplane Company); the B-58 
(Robert Widmer, Vice President, General Dy- 
namics/Ft. Worth), and numerous others. 

Perhaps the most striking result of the activ- 
ity was the general management consensus 
concerning ways to reduce costs in govern- 
ment programs, particularly when the find- 
ings are compared to current NASA manage- 
ment practices. 
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The study reached the somewhat subjective 
conclusions that to reduce program costs, 
NASA should: 

1. State requirements as objectives, and 
leave them relatively unconstrained. 

2. Not start building flight hardware until 
all major technological uncertainties 
have been resolved. 

3. Utilize small, hand-picked government 
program offices and contractor teams. 

4. Eliminate (or greatly reduce) 
government-imposed changes. 

5. Allow contractors maximum autonomy. 

6. Once program definition has resolved 
major technological uncertainties, com- 
plete the development process as quick- 
ly as possible. 

NASA management agreed to try many of 
these potential cost-saving cultural differ- 
ences. However, the cultural inheritance, a 
result of using many of the same management 
and contractor teams from the Apollo pro- 
gram, soon overcame many planning ambi- 
tions. Except in a few notable areas, the origi- 
nal culture was not appreciably changed, ex- 
cept where it had to be adapted to survive the 
newly cost-constrained environment. 

These 1971 studies further concluded that pro- 
gram cost estimates made within company en- 
gineering departments are generally ade- 
quate. However, since bidders usually under- 
estimate costs to increase the likelihood of 
winning hardware contracts, overruns often 
occur. Research performed recently supports 
this finding; in fact, professional cost estima- 
tors have found that this buy-in effect has be- 
come one of the major contemporary problems 
of program cost analysis. 


The 1971 studies observed that program con- 
trol techniques similar to the DoD C/SCSC are 
effective and essential, but excessive control 
(or micro-management) is a deterrent to good 
performance. And finally, and probably most 
important to current and future programs, it 
was found that concurrent development of mu- 
tually dependent, high technology items is es- 
pecially difficult unless strong unified man- 
agement is provided. 

Lessons Learned from Space Shuttle 

Between 1977 and 1979 a series of studies was 
performed as a result of budgetary problems 
encountered in the peak funding years of the 
Space Shuttle program. These studies univer- 
sally found that although the technical aspects 
of the program were being managed very well, 
some management problems existed. For ex- 
ample, the Day Committee, headed by LeRoy 
E. Day, found that peak funding problems had 
occurred as a result of almost universal inat- 
tention to the "budget year”; i.e., two years 
into the future. So much was the preoccupa- 
tion with the current ("operating”) year, that 
little attention was paid to the budget year. 
Often, contractor estimates were employed 
with little analysis to predict the program re- 
quirements. The Day Committee found that 
this problem could have been avoided by inde- 
pendent analysis of contractor estimates by 
the government. The committee also found 
that NASA in general did not apply enough 
analytical manpower to programmatic, espe- 
cially budgetary, tasks. (The results of the 
studies were never published but are on file in 
the JSC Cost Estimation Data Bank.) 

Prior to his departure from NASA, a Space 
Shuttle program manager was interviewed ex- 
tensively to obtain his perspective on lessons 
learned from the program, particularly in the 
program management areas, including cost es- 
timating and program control. He made the 
following observations. 


45 


Management and Budget Lessons, The Space Shuttle Program 


• If the "bottom line” of success is obtaining a 
successful program result for the least 
money, then the management systems 
used were successful. 

• No amount of money early in the program 
would have prevented the technical prob- 
lems (the Space Shuttle Main Engine de- 
velopment problems and the Thermal Pro- 
tection System tile problems, primarily). 

• Ninety-five percent of the problems with 
our budget system have nothing to do with 
the mechanics of program control. They 
are more related to the way we organize 
and review our budget; pressures to be 
over-optimistic in the budgeting process; 
the interfaces we have with the Congress 
and the Administration; and coming to 
grips with problems we predict. 

• Over-optimism is popular, and the process 
encourages it. 

• The budget cycle can be improved. Budget 
calls probably should not dictate a sched- 
ule: project personnel should be asked to 
predict the schedules they can make and 
the dollars they need to make them. 

• The prediction of program cost reserves 
should receive more emphasis, at all levels 
of the program. Program reviews should 
solicit issues and create a climate for re- 
solving budget problems, not only techni- 
cal issues. Reviews should emphasize the 
pedigree of cost and schedule estimates, 
the degree of optimism or pessimism 
(risk), and the likely program cost growth. 
Reviews should reflect the best estimates 
of cost reserves required for contingencies. 

• Program control should emphasize quanti- 
tative measurement of progress, and focus 
on future projections based on past perfor- 
mance (e.g., manhours per foot of welds on 
the External Tank). 


Program Control and Management 
Processes 

A number of the factors influencing program 
success were also explored in a survey submit- 
ted to all senior managers of the Space Shuttle 
Program. Program managers were asked to 
rank management factors or processes which 
favorably influenced the outcome of the pro- 
gram. The most highly ranked items were: 

1. Actions of the program manager (e.g., 
timely decision-making, effective man- 
agement leadership); 

2. Adequacy of the original cost estimates; 

3. Actions of the program director (e.g., 
budget leadership, timely resolution of 
program conflicts); 

4. NASA resource management processes 
employed by the program manager’s 
staff; and 

5. NASA resource management processes 
employed by the program director’s 
staff. 

The three least effective influences (neutral, 
slightly influential, or of negative influence) 
on program success were found to be: annual 
funding limitations by the OMB and Congress 
(this is an example of an influence completely 
outside the control of program management); 
the Cost Limit Review Board (CLRB) (a NASA 
Headquarters body that screened major 
changes); and the performance manage- 
ment/measurement system, which was ranked 
so low as to indicate that it might have even 
been counterproductive. At least, it was never 
used effectively. 

Program managers were also asked to sepa- 
rately rank only the management processes 
which had had the most influence on the suc- 
cessful outcome of the program. 
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The most highly regarded process was the in- 
dependent assessment function performed by 
the program office at JSC; second, the cost es- 
timation process; third, the budgeting process 
(despite its flaws); and fourth and least effec- 
tive, the performance management/measure- 
ment system employed. 

A few other factors making major contribu- 
tions to the favorable program cost outcome 
were: early system definition and configura- 
tion change control; change of program con- 
tent (content was reduced at several points in 
the program); contractor willingness to accept 
risk; and good analogous data on which to base 
cost estimates. 

Many of the managers said that too much 
management time was diverted from signifi- 
cant problems by excessive budget-related 
problems which occurred at the peak of the 
program. Six actions were suggested: 

1. End overly close alliances with contrac- 
tors; 

2. Allow projects to keep change reserves 
within their budgets; 

3. Plan the program to realistic resource 
limits; 

4. Clarify the responsibilities of all pro- 
gram levels early in the program; 

5. Treat escalation realistically; and, 

6. Accurately assess development time. 

Management responses were far from unani- 
mous on these influences, however. For exam- 
ple, a former program director responded that 
accurate cost estimates at the outset of a pro- 
gram are often counterproductive, in that they 
provide ammunition for the opponents of the 
program. This lent further credibility to the 
conclusion that program proponents often do 
not want to know the true costs of a program, 


as total cost magnitudes can be a deterrent to 
successfully selling the program in the politi- 
cal environment. 

Summary and Conclusions 

Perhaps the major lesson to be learned from 
this type of analysis is that it is extremely dif- 
ficult, primarily for reasons of cultural inertia, 
to change a management practice from one 
program generation to the next. Lessons 
learned are often either forgotten or not easily 
incorporated into the management culture. 

I shall not repeat here the conclusions of the 
various studies mentioned above. However, I 
will describe a pattern that has emerged over 
two generations of analyses. 

First, the program planning process has a 
significant effect on the outcome of a program. 
Programs with longer definition phases have 
proven to have the least cost and schedule 
overruns. Accurate initial budgets, provided 
by accurate program cost estimates, have uni- 
versally been cited as a requirement for suc- 
cess. Accurate budgets have a stabilizing ef- 
fect on the program; inaccurate budgets lead 
to the spending of inordinate management and 
other program resources on replanning, re- 
scoping, recosting, and rescheduling activities. 

Second, NASA has in the past not done the 
best possible job of budgeting during the peak 
years of a program, relying too heavily upon 
contractor cost projections, and not providing 
agency or program management with enough 
resource reserve flexibility to respond to pro- 
gram uncertainties. The NASA budget pro- 
cess must be reformed to provide more inter- 
nal NASA analysis and less reliance upon con- 
tractor estimates. Far more emphasis on run- 
out years is needed. 

Third, there is enormous pressure at the be- 
ginning of a program to estimate the actual 
costs to be lower than historical trends might 
indicate. Lower estimates simply increase 


47 


Management and Budget Lessons, The Space Shuttle Program 


the probability that the program will overrun 
its costs. Program managers feel that they 
will be able to do better than their predeces- 
sors, and they are often willing to assume high 
risk in initial program estimates to help sell 
the program in the political arena. 

Because hardware contracts are always com- 
petitively awarded, the proposer must tread a 
fine line between cost estimate credibility and 
the risk of losing out to a competitor offering a 
lower price. As David Novick, the father of 
modern cost estimation, said in 1962, "The in- 
centives to estimate low are much greater 
than the penalties, if indeed there are penal- 
ties.” In the quickly changing NASA environ- 
ment, the contractor knows that if indeed a 
winning bid is too low, actual costs can be re- 
covered through the acquisition process (usu- 
ally cost-plus-fee), plus the cost of any changes 
made. 

Fourth, NASA has consistently used three 
tiers of program offices, often large organiza- 
tions with different points of view, despite evi- 
dence that many of the most successful aero- 
space programs have been effectively man- 
aged by very small program offices. 

NASA has evolved to a management style 
which mixes government and private sector in 
the technological decision-making processes. 
This highly interactive style produces a tech- 
nically superb product, but also causes an 
enormous change workload that often results 
in costly program changes. While a former 
Space Shuttle program manager denies that 
any nonessential changes were made, the pro- 


cess is driven by thousands of detailed 
changes, often stimulated by the NASA engi- 
neering community itself (as opposed to a pro- 
cess driven by broadly-stated program re- 
quirements). This process has been assessed 
by many senior program managers to be very 
costly. 

Performance management/meaurement sys- 
tems previously used by NASA have consis- 
tently been either ignored or blamed for not 
revealing problems in time to resolve them. 
Future systems should be designed to cope 
with the unique requirements of a particular 
program environment, as opposed to using sys- 
tems from previous programs. 
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THE 'MANAGERS’ ONLINE SERVICE 

(REVISED) 

A current awareness service entitled MAN- 
AGERS is available online through the 
NASA/RECON system. Twenty citations and 
abstracts of books, journal articles, and reports 
are selected each week as those recent addi- 
tions to the STT Database most likely to be of 
particular interest to NASA managers. The 
items included are updated every Monday 
morning. 

These items are selected for their timeliness 
and pertinence to NASA’s mission, manage- 
ment, and foreign technology exchange. Use 
of this service allows NASA managers and 
other interested individuals to stay abreast of 
new developments in a wide variety of subject 
areas covering the interests of managers in 
various fields. 

Those who are interested in reviewing these 
weekly selections may execute the 
MANAGERS stored search from within File 
Collections A, B, D, N, O, or P in 
NASA/RECON. For those who do not have 
individual RECON passwords, the service is 
available through the local technical libraries 
at all NASA Centers and many NASA 
contractors, as well as through the libraries of 
some other government agencies and their 
contractors. 


To see the selected citations and abstracts, the 
reviewer can sign into RECON and follow 
these steps: 

STEP 1: Type BB A/E (press enter) 


STEP 2: Type QUERY EXECUTE 

MANAGERS (NAHQ) (press enter) 

The system will respond: MANAGERS 
EXECUTION BEGINS. This stored search 
will then retrieve from the STI Database 
those 20 accessions which are that week’s 
selections, and place them into Set 1. Once 
execution is completed, the system will re- 
spond: END SEQUENCE MANAGERS 
EXECUTION. 

STEP 3: Type DISPLAY 1 (press enter) 

This allows review of the first citation in 
the set. Subsequent citations may be 
shown by typing DISPLAY and pressing 
the enter key. (Dial-up users may also use 
either the TYPE or BROWSE command in- 
stead of DISPLAY.) 

Some of the subject areas covered by the week- 
ly service are: 

• Current aerospace technology on 
present and future NASA space mis- 
sions, including aerospace medicine. 

• Technologies of the European space pro- 
gram as well as those of the U.S.S.R. 
and Japan. 

• New management methods, business 
trends, and policies concerning procure- 
ment, financial, contract, personnel, 
and research management. 

• Congressional and legislative reports, 
federal budgets, and appropriations of 
the NASA program. 
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• New developments in database man- 
agement systems and software. 

• Current reports on international trade, 
market research, and economics. 

• Current technology transfer, assess- 
ments, and utilization. 

• Current reports on international rela- 
tions, cooperation, and space law. 

Some sample titles included in the 
MANAGERS service have been: 

• The Three R’s of Training: Recording, 
Retaining, and Reporting — the Train- 
ing Management that Synergizes 

• The NASA Information Life-Cycle 
Transition Management within the 
Software Project 

• U.S.-Soviet Space Relationships in the 
1990’s -- A U.S. Perspective on Policy 
Alternatives 

• NASA’s New University Engineering 
Space Research Programs 

• The Law and Regulation of Internation- 
al Space Communication (book) 

Copies of reports or articles found in MANAG- 
ERS may be ordered from your local technical 
library. 

Citations entered weekly are among those in- 
cluded in the annual publication Manage- 
ment: A Bibliography for NASA Managers 

(NASA SP-7500). For additional information, 
contact RECON/Reference Services, (301) 
621-0150. 


BOOK REVIEWS 

Effective Project Planning and Manage- 
ment: Getting the Job Done , by W. Glen 
Randolph and Barry Z. Posner, 1988. 
Prentice-Hall, Englewood Cliffs, N.J. 

A self-help book for project managers? After 
eight years of leading seminars on effective 
project planning and management, these two 
professors with doctorates in business admin- 
istration from University of Massachusetts 
wrote this book for managers in the broadest 
sense, from housekeepers to engineers. It be- 
gins with a self-scoring inventory and ends 
with inspirational advice to follow 10 simple 
rules. 

The "planning” section consists of a catchy 
acronym for management by objectives: GO- 
CARTS. First, set a clear Goal. Then deter- 
mine your Objectives. Establish Checkpoints 
(milestones), Activities (tasks). Relationships 
(among activities) and Time estimates. The S 
stands for Schedule, pictured in a bar or flow 
chart. Simple enough, and the authors apply 
the GO-CARTS to Noah’s Ark, suggesting per- 
haps a better way to get ready for The Flood. 

The "managing” section consists of another 
acronym: DRIVER. Direct people individ- 
ually and as team members. Reinforce their 
commitment and Inform everyone of every- 
thing. Then build agreements (conflict resolu- 
tion) that Vitalize team members, and Em- 
power yourself and others with a greater sense 
of purpose in the project. Finally, Rule 10, en- 
courage Risk-taking (creativity). 

The rules and acronyms may seem contrived 
and overly simplistic, but the authors provide 
several lively anecdotes, cartoons and even 
comic strips. 
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The Leadership Factor , by John P. Kotter, 
1988. The Free Press, New York. 

Armed with questionnaires, interviews and 
case studies, Harvard Business School profes- 
sor John Kotter identifies and validates four 
consecutive factors that create outstanding 
leadership: inborn capacity, early childhood 
experiences, formal education and career ex- 
periences. These factors seem to determine a 
great leader’s keen mind, strong interpersonal 
skills, lofty integrity and high energy drives. 

While such information is not exactly earth- 
shaking, Kotter’s observation — based upon 
empirical data — is that "very few firms have 
sufficient people with those skills and assets.” 
He describes this as an "increasingly serious 
problem.” Lee Iacocca is the only leader sin- 
gled out, and Johnson & Johnson the only 
management team that measures up to such 
leadership standards. Most of the failures are 
disguised by fictitious names. 

To attract and keep better leaders, Kotter sug- 
gests a sophisticated recruiting effort (not 
based on "personnel” trivialities) to seek out 
the leaders of tomorrow; an attractive ("fun”) 
work environment, free of games, politics and 
bureaucracy; challenging, decentralized op- 
portunities; systematic, early identification of 
potential and development needs; and 
planned, formal development opportunities. 
The burden, he says, is on the shoulders of hu- 
man resource professionals to look for and cul- 
tivate those who show innate and earned lead- 
ership potential, instead of being technically 
competent. 

Thus, The Leadership Factor is more global 
and analytical than practical, a follow-on to 
his more popular The General Managers 
(1982) and Power and Influence (1985). 


Kelly Johnson, perhaps the most honored 
aeronautical engineer alive today, is best 
known for his "Skunk Works” at Lockheed — 
an innovative project management concept 
that produced the U-2 and SR-71 "Black Bird” 
on schedule and under budget. 

More Than My Share is the personal reflection 
of Kelly Johnson, edited by Maggie Smith. 
The seventh of nine children of a stern but not 
severe Swedish bricklayer who took the wrong 
train to Nebraska and ended up in Wisconsin, 
Kelly invented his nickname in grammar 
school after busting the leg of the school bully 
who called him "Clara.” "Kelly”, taken from 
an Irish fighting song popular at the time, 
stuck. 

'T have known what I wanted to do since I was 
12,” recalls Kelly. But to get an aeronautical 
engineering degree at the University of Michi- 
gan during the Depression, he had to study 
civil, chemical, electrical and mechanical en- 
gineering — "an excellent curriculum because 
it provided a very good basic education in ev- 
erything it took to design and build an air- 
plane,” he recalls. He had only two dates in 
college and had to feed an ulcer with dough- 
nuts and milk constantly. Unable to find a job 
after graduation, and with eyesight too poor 
for the Army Air Corps, Kelly returned to Ann 
Arbor for graduate study in aerodynamics un- 
til he was hired by Lockheed for $83 a month 
in 1933. 

During that time Kelly proved his aeronauti- 
cal expertise, and was sought out by Amelia 
Earhart, Howard Hughes, and the Lindbergs. 
With Anne Lindberg’s approval, he fashioned 
his guiding principles of life: belief in God, 
good health, purpose in life, a spouse who loves 
and understands you, and respect for superiors 
and subordinates. 


Ten years later, Kelly promised the Army Air 
Corps that Lockheed would build, in 180 days, 
a match for the jet-powered Messerschmitt 
262. But Lockheed was booked up, already 


Kelly: More Than My Share of It All , by 
Clarence L. "Kelly” Johnson, 1985. The 
Smithsonian Press, Washington, D. C. 
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running three shifts six days a week for the 
war effort. Kelly, given a free rein, "stole” 22 
trusted Lockheed engineers from the main fac- 
tory, and retrofitted an old machine shop with 
spares, scrap lumber and a rented circus tent. 
The YP-80A, the nation’s first tactical jet 
fighter, also the first to break 500 mph, was 
accepted by the Air Corps 143 days later. His 
secret, ragtag, makeshift, independent opera- 
tion was known as "Skunk Works”, reminis- 
cent of Li’l Abner’s kickapoo joy juice, a hasty 
brew that included skunks. 

Chapter 16, "It’s No Secret,” is chock full of 
management techniques used in the dozen or 
so "Skunk Works” operations Kelly conducted. 
Early on at Lockheed he learned two lessons 
from chief engineer Hale Hibbard which con- 
tributed to the success of "Skunk Works”: ex- 
cellent labor relations, and "it is much better 
to lead people, not to drive them.” He also be- 
lieved that those who design aircraft should 
also fly them, and Kelly insisted on inviting 
employee families to aircraft christenings. He 
carried quarters around with him for anyone 
who could prove him wrong on anything. 

Throughout the years, Kelly’s first two wives 
suffered and died. Recently he was funding a 
hospice at a Burbank hospital for family mem- 
bers, and because "life is too short,” he mar- 
ried Nancy Johnson. "The final chapter of my 
life is not yet written,” Kelly concludes. "But 
if God should call me tonight, I will have had 
more than my share of it...” 


Engineering Management , by David I. Cle- 
land and Dundar F. Kocaoglu, 1981. McGraw- 
Hill, New York. 

Believing "the time has come” for engineering 
management to be recognized as a distinct dis- 
cipline, the two founders of the U. of Pitts- 
burgh’s engineering management program set 
out to define, describe and explain what engi- 
neers need to know when they become manag- 
ers. To do this, they concentrate on manage- 


ment theory as applied to engineering, skill in 
linear programming, and the "values and aspi- 
rations” in the attitudes of an engineering 
manager. 

While the 469-page book does not deal with fi- 
nances nor economics, it does attempt to quan- 
tify the subjective values of decision-making. 
A "hierarchical decision model” in the appen- 
dix pulls together much of the probability the- 
ory of earlier chapters for use in project plan- 
ning, evaluation and resource allocations. The 
book winds down with environmental con- 
cerns and legal implications of engineering 
management. 

Cleland had authored a standard textbook ear- 
lier, called Systems Analysis and Project Man- 
agement , and later co-edited the Project Man- 
agement Handbook (reviewed in NASA SP- 
6101). Kocaoglu used a systems approach in 
his 1976 doctoral dissertation at Pitt. Here, 
however, the emphasis is not on systems anal- 
ysis but rather upon engineering. The engi- 
neer who has little knowledge of management 
will find more of interest than the manager 
with little skill in engineering. Using the 
mathematical models of engineering, the tech- 
nical specialist is introduced to management 
responsibilities. 

Engineering Management is a bit dated but 
useful as a graduate-level textbook and as an 
orientation for engineers who find themselves 
as managers of projects and people. 


The Implementation of Project Manage- 
ment: The Professional’s Handbook , ed- 
ited by Linn C. Struckenbruck, 1987. 
Addison-Wesley, Reading, Mass. 

The Southern California chapter of the Project 
Management Institute spent two years pro- 
ducing this how-to manual for executives who 
find themselves in the role of project manage- 
ment. Dr. Linn Struckenbruck, professor of 
safety and systems management at USC, 
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served as coordinator and provided about half 
the material in this oversize (9 by 12) hand- 
book. 

'This book will discuss the methods and proce- 
dures used by successful project managers, 
and will point out the pitfalls to be avoided in 
implementing a project,” the editor proclaims 
at the outset. The project manager is an ex- 
ecutive who assumes an additional role - inte- 
gration - and becomes ultimately responsible 
for a large, well-defined but complex project. 
Hence, the emphasis here is upon the matrix. 

Matrix is defined as a dual- authority relation- 
ship between the project manager and the 
functional line manager. The balance of pow- 
er is in the hands of the former in a tight or 
strong matrix and with the latter in a weak or 
loose matrix organization. The ideal is either 
a balance of power by dividing the responsibil- 
ities into overall integration and technical di- 
rection, or to shift the balance depending on 
budget and schedule. In either case, top man- 
agement support of the matrix concept is fun- 
damental. 

More traditional management theories are 
presented, such as management by objectives 
(MBO). Fred Peters, chief of programs, sched- 
uling and analysis at Johnson Space Center, 
co-authors one chapter on MBO in project 
management. MBO is described as an empha- 
sis on results instead of activities in a goal- 
oriented project. Yet even the MBO can be in- 
corporated into a matrix when the project 
manager obtains specific objectives in writing 
from functional personnel as a way of firming 


up positive commitments. These concrete ob- 
jectives then become useful yardsticks in per- 
formance evaluation. Pitfalls are listed, but if 
the objectives are achievable and verifiable, 
MBO can be a useful tool, for the project man- 
ager, even in a matrix organization. 

Eight appendices with sample charts add to 
the value of this handbook. While style and 
approach vary among the dozen or so writers, 
with considerable overlap. The Implementa- 
tion of Project Management is quite readable. 
Three case histories in the back show applied 
theory and underscore the lessons learned. 


Management: A Bibliography for NASA 
Managers (NASA SP-7500) 

Scientific and Technical Information Division, 
annual. This bibliography is a collection of re- 
ferences selected from the unclassified reports 
and journal articles announced in the NASA 
STI Database. The references are selected 
based on their timeliness and pertinence to 
NASA’s mission, management and foreign 
technology exchange. The items are grouped 
into 10 categories, especially chosen for this 
bibliography, ranging from Human Factors 
and Personnel Issues to Management Theory 
and Techniques. Seven indexes are included: 
subject, personal author, corporate source, for- 
eign technology, contract number, report num- 
ber, and accession number. Available from 
the National Technical Information Service. 
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